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


DevOps Rompiendo barreras

Les comparto la presentación de la charla que tuve la oportunidad de compartir en EAFIT en octubre de 2013

viernes, 18 de julio de 2014

Coding Kata - Procesamiento de Ordenes de Compra

Definición inicial de la necesidad de negocio

Imagina que estas escribiendo una aplicación para procesar ordenes de una gran compañía. En el pasado esta compañia usaba una mezcla aleatoria de reglas manuales y automatizadas (Ad hoc) para manejar las ordenes. Ellos ahora quieren hacer de una sola forma el manejo de la ordenes: Tu aplicación. Sin embargo ellos y sus clientes están muy apegados a la diversidad de sus reglas de negocio por lo que quieren que se incluyan todas esas reglas en el nuevo sistema. 

Cuando conoces a las personas que hoy manejan las ordenes descubres que sus practicas de negocio se acercan al caos: No hay dos lineas de producto que tengan las mismas reglas. Peor aún. Muchas de sus reglas no están escritas: Muchas veces te dirán cosas como esta: "Oh, carol en el segundo piso se manejan este tipo de ordenes".

Durante el primer de reuniones decidiste enfocarte en los pagos y particularmente en el procesamiento requerido cuando un pago ha sido recibido por la compañía. Llegas a casa exhausto con una carpeta llena de pedazos de reglas como: 

- Si el pago es para un producto físico, generar una orden de entrega para la compra.
- Si el pago es por un libro, crear un duplicado de la orden de entrega para el departamento  de libros.
- Si el pago es para una membresía. Activarla
- Si el pago es para actualizar una membresía. Aplicar la actualización
- Si el pago es para una membresía o actualización, enviar un mail al dueño e informando de la activación o actualización.
- Si el pago es por el video "Aprendiendo a eskiar", agregar un video primeros auxilios gratis al paquete de entrega (Resultado de una decisión legal en 1997).
- Si el pago es por un producto físico o libro, generar un pago de comisión al agente.

Y cada día para tu horror obtienes mas y mas paginas de estas reglas cambiantes.

Ahora te enfrentas a implementar este sistema. Las reglas son complicadas y arbitrarias. Aún mas, tu sabes que van a seguir cambiando: Una vez el sistema este funcionando aparecerán todo tipo de casos especiales.

OBJETIVO: Como puedes domesticar estas reglas de negocio salvajes?. Como puedes construir un sistema lo suficientemente flexible para manejar tanto la complejidad como la necesidad de cambio?. Como puedes hacerlo sin condenarte a años y años de soporte?

Traducido de codekata.com

martes, 24 de junio de 2014

Integración de Jenkins con BitBucket

El asunto del titulo parece bastante simple y de hecho lo es. Pero al intentar realizar un fetch de una aplicación alojada en bitbucket a través de autenticación basada en HTTPS, obtuve los siguientes errores:

Error 1

Started by user Juan mauricio Giraldo parra
Building remotely on 262ce1a4 in workspace /scratch/jenkins/workspace/AtlasTeam
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url https://yuytyutury:ggyutyutryut@bitbucket.org/danielbustamante/atlasteam.git
Fetching upstream changes from https://bjgjhghghjgh@bitbucket.org/danielbustamante/atlasteam.git
 > git --version
 > git fetch --tags --progress https://kjhjkhkjhkjh@bitbucket.org/danielbustamante/atlasteam.git +refs/heads/*:refs/remotes/origin/*
FATAL: Failed to fetch from https://mhjjkhjkhkjhkj@bitbucket.org/danielbustamante/atlasteam.git
hudson.plugins.git.GitException: Failed to fetch from https://nmbhgjhghghjghj@bitbucket.org/danielbustamante/atlasteam.git
 at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:622)
 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:854)
 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:879)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:662)
 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:571)
 at hudson.model.Run.execute(Run.java:1665)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:246)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://nhjghjgjhgjgjhg@bitbucket.org/danielbustamante/atlasteam.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: Authentication failed

 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1325)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1186)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:257)
 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
 at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
 at hudson.remoting.UserRequest.perform(UserRequest.java:118)
 at hudson.remoting.UserRequest.perform(UserRequest.java:48)
 at hudson.remoting.Request$2.run(Request.java:328)
 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)


Error 2

Started by user anonymous
[EnvInject] - Loading node environment variables.
Building on master in workspace /var/lib/jenkins/workspace/TccWebServices_BS
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url https://sfsfdsdf:sdadasdads@bitbucket.org/danielbustamante/atlasteam.git
Fetching upstream changes from https://mauriciogiraldo@bitbucket.org/danielbustamante/atlasteam.git
 > git --version
 > git fetch --tags --progress https://nghjghjghjgfhg@bitbucket.org/danielbustamante/atlasteam.git +refs/heads/*:refs/remotes/origin/*
FATAL: Failed to fetch from https://mnghjghjghjgjfhj@bitbucket.org/danielbustamante/atlasteam.git
hudson.plugins.git.GitException: Failed to fetch from https://jhghjghjgfhjhjg@bitbucket.org/danielbustamante/atlasteam.git
 at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:623)
 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:855)
 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:880)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1414)
 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
 at hudson.model.Run.execute(Run.java:1678)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:231)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://hgfghfhgfghfgh@bitbucket.org/danielbustamante/atlasteam.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error: The requested URL returned error: 401 while accessing https://khkhkjhjkhkjkjh@bitbucket.org/danielbustamante/atlasteam.git/info/refs

fatal: HTTP request failed

 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1325)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1186)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:257)
 at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:621)
 ... 10 more

En los foros de internet la respuesta a este error era siempre la misma. Desde la versión 1.4.0 el issue fué solucionado. Nosotros teníamos instalada la versión 2.2.2 y aún así no funcionaba. Intentamos muchas cosas hasta que decidimos bajar la versión del plug-in Git de Jenkins a la versión 1.4.0 y se hizo la luz. Al parecer la ultima versión del plug-in tiene un problema con la autenticación HTTPS.

Los desarrolladores no consideramos el mal que podemos causar al entregar liberaciones de producto a producción sin asegurar adecuadamente la calidad. Fué 1 semana de trabajo que nos retrasó en cierta medida el proyecto. :-(




viernes, 20 de junio de 2014

De construcción de software a Desarrollo de Producto

Los procesos de desarrollo de software han cambiado en el tiempo. Aprendimos que a diferencia de una cadena productiva, nuestro trabajo no es mecánico y repetitivo sino en gran parte producto de la creatividad y la colaboración de equipo. Esta es la razón por la cual las metodologías ágiles han tenido tanta aceptación en el medio pues se enfocan radicalmente en estos conceptos.

SCRUM como proceso base para implementar software, plantea algunas ceremonias, se orienta al valor haciendo primero lo mas importante y asumiendo el alcance como un ente variable, pero cuando la responsabilidad del diseño del producto se deja solo en manos del Product Owner, llevamos a los equipos de desarrollo nuevamente a la construcción de funcionalidades, preocupándose por mantener una velocidad estable en el tiempo y por cumplir los compromisos establecidos en las ceremonias.

Tradicionalmente hemos separado las fases de análisis y de diseño del software, percibiendo el análisis como la definición funcional o el comportamiento que el software tendrá en ejecución, y pensamos en el diseño como la estrategia tecnológica que nos permitirá implementar dichas funcionalidades. Muchas veces el Product Owner se dedica al análisis en conjunto con el negocio y el equipo de desarrollo al diseño y la implementación. Ha cambiado la forma como nos comunicamos pero seguimos estando separados.

La verdad es que el diseño de un producto va mas allá de la forma como se estructura el código fuente o de los servidores y maquinas donde será desplegado para servir las peticiones de los usuarios. Un software es un generador de capacidades de negocio y en este orden de ideas el diseño del producto incluye las funcionalidades que deberán ser implementadas en torno a conseguir el impacto que se requiere.

Un equipo de desarrollo de software podría ser mucho mas efectivo si trabaja de forma conjunta con el Product Owner, teniendo una clara visión de lo que se quiere lograr y apoyando al negocio en su definición. La verdad es que las personas del negocio no saben diseñar soluciones, ellos conocen a la perfección lo que hacen y lo que quieren lograr y a partir de estos deseos definen una serie de funcionalidades que en su opinión les permitirán conseguir eso que desean. Pero esas definiciones corren el riesgo de quedarse en simples funcionalidades que no articulen un verdadero producto.

Si nuestra posición como desarrolladores se centra en la codificación, en conocer mucho sobre lenguajes de programación, patrones de diseño, arquitectura y tecnología, entonces será suficiente recibir como insumos un conjunto de cosas por hacer. Pero si nuestro objetivo es la generación de nuevas capacidades de negocio, e impactar la calidad de vida de las personas haciendo su trabajo mas fácil a través de la adopción tecnológica, entonces debemos ir mucho mas allá, conocer los objetivos que quiere lograr nuestro cliente (Persona o empresa) y velar porque los productos que entreguemos sean de la calidad mas alta e impacten de la forma mas positiva en estos.

Para llegar a este punto debemos cambiar la forma como medimos el resultado de lo que hacemos. Normalmente el trabajo creativo no tiene un resultado tangible e inmediato como si lo puede ser la construcción de código fuente, pantallas y funcionalidades. El análisis creativo que conlleva a diseñar productos que impacten a los clientes incluso mas allá de lo que ellos mismos esperan, requiere dejar de producir de forma constante, a grandes cantidades y pasar a producir menos con mayor efectividad. Es decir el foco del equipo deja de ser la productividad y pasa a ser la efectividad en la generación de impacto. 
Construir mas funcionalidades no se traduce en generar mas impacto, al contrario: Mayor cantidad de funcionalidades conlleva a tener mas código fuente, este a su vez incrementa la complejidad, lo que aumenta los tiempos de mantenimiento, reduciendo de esta manera la rapidez con la que se generan mas capacidades al software existente, llevando finalmente a tener negocios menos competitivos.

Mary y Tom Poppendieck en su libro The Lean Mind Set, hablan de esto en detalle y plantean lo siguiente: "Asking software developers to write more code is like asking authors to put more words in their books or to teachers to put more children in their class rooms. When creativity and learning are important, focusing on quantity makes none sense" Mary y Tom Poppendieck

En este orden de ideas preguntarse como las metodologías ágiles incrementarán la productividad de los desarrolladores puede ser absurdo, pues nuestro objetivo es desarrollar las funcionalidades esenciales que los usuarios amarán y no mas que eso.

La pregunta ahora es ¿Como las metodologías ágiles me ayudan a lograr equipos mas efectivos?

sábado, 24 de mayo de 2014

The Happinnes Advantage

Durante el año en curso he enfocado toda mi energía en adquirir ciertos Soft Skills necesarios para enfrentar mis retos personales y profesionales. Esto me llevó entre otras cosas a un libro cuyo contenido ha sido revelador y el cual quiero compartir. Se llama The Happinnes Advantage. The Seven Principles Of Positive Psychology That Fuel Succes and Performance at Work, de Shawn Achor.

Llegué a él porque durante mucho tiempo cuestioné la definición de éxito profesional que promulga el mundo: Poder, Tener, Estar, Llegar, Ascender. De hecho toda mi vida giraba en torno a esto pero con una constante: Cada vez que conseguía lo que quería el sentimiento de gozo llegaba y poco después simplemente se esfumaba. Entonces ¿Que es ser feliz?. Mi abuela siempre dice: "Trabaje duro mijo para que le vaya bien en la vida", y en muchos de mis amigos escuchaba frases como "Voy a trabajar duro por un tiempo para conseguir lo que quiero y luego me podré relajar".

Lo irónico de todo esto es que la ciencia ha descubierto que la felicidad no es una consecuencia de nuestros logros. Sino al contrario. Cuando somos felices podemos conseguir fácilmente todo lo que deseamos. 


La felicidad no es mas que un estado mental que dispara una serie de reacciones químicas al interior del organismo para finalmente generar un sentimiento de bienestar que llamamos "Felicidad". Al ser un estado mental no depende del lugar en el que estemos, ni del dinero que tengamos en el banco, ni de las propiedades, las circunstancias, las personas o cualquier otro factor externo a nosotros. La felicidad simplemente nace al cambiar la forma como vemos al cosas, al agradecer, al valorar, al recordar, al divertirse, al no pensar excesivamente en la incertidumbre del futuro y al no angustiarse innecesariamente por lo que ya pasó. Suena simple ¿No? De hecho casi podríamos decir que es sentido común: "Para que preocuparme si finalmente solo hay dos salidas: Las cosas salen como espero que salgan o no salen como yo lo espero. El hecho es que sentido común no significa accionar común. Es decir, el simple conocimiento de algo no genera cambios y accionables en nuestro interior, si fuera así ningún médico fumaría pues saben perfectamente que en el tiempo eso los matará. 

El libro del que hablé es una muy buena referencia para iniciar un cambio de vida, para afrontar las cosas diferentes y para tener una única restricción en todo lo que hacemos en la vida: SER FELICES y al serlo podremos con seguridad hacer felices a todos los que nos rodean.

El poder del cerebro

Como ya lo mencioné la felicidad es un estado mental que dispara una serie de reacciones químicas al interior del organismo, las cuales a su vez generan una sensación de bienestar. Estas reacciones producen tres hormonas: Serotonina, Endorfina y Dopamina. Nuestro objetivo es entonces tener un estilo de vida que promueva su producción. ¿Como lograrlo?. La actitud es la clave de todo. Nosotros decidimos como vemos el mundo: ¿Pierdo tiempo en los embotellamientos viales o simplemente lo aprovecho y leo un libro?, ¿Considero que la charla a la que me citaron es una perdida de tiempo porque el expositor no tiene idea de lo que habla, o me permito observar y aprendo sobre lo que no debo hacer al exponer?, ¿El vaso esta medio lleno o medio vacío?. Esto suena a frase cajón y de hecho durante mucho tiempo pensé lo mismo pero al final comprendí algo clave y es que no puedo controlar el  mundo pero sí me puedo controlar individualmente. No puedo predecir el hecho de que un servidor salga de línea y deje a toda la compañía parada perdiendo dinero, pero si puedo controlar la forma como reacciono ante este suceso. ¿Llorar, Gritar, Preocuparme, Pensar que me van a despedir por todo el dinero que mi organización esta perdiendo? o simplemente pensar que ésto al igual que todo lo que me pasa en la vida es una situación mas por resolver. De hecho lo que normalmente llamamos problemas no son mas que asuntos inconclusos que ponen en riesgo algo que nos interesa, por esta razón lo único que podemos hacer es actuar. Preocuparse no soluciona absolutamente nada.

Pero todo esto tiene una explicación genética. El cerebro esta diseñado para mantenernos vivos, no para hacernos felices. Esa es la razón por la cual ahora somos los animales mas desarrollados en la linea de evolución y para lograr su propósito nuestro cerebro todo el tiempo muestra, riesgos, amenazas y peligros que en su conjunto forman todos los miedos que gobiernan nuestra existencia y el miedo es el mayor enemigo de la felicidad pero el mayor aliado de nuestra supervivencia. Ahora los peligros son diferentes: Ya no tenemos tigres diente de sable acechando en la selva, pero tenemos jefes, gobiernos, comercio, dinero y cualquier otra cantidad de cosas que amenazan nuestra supervivencia O al menos eso es lo que cree nuestro cerebro.

Los 7 principios

A continuación los 7 principios de los que habla Shawn Achor en su libro:

1. The Happines Advantage


Albert Eisntein Dijo: "Loco es aquel que quiere obtener resultados diferentes haciendo siempre lo mismo". Entonces lo mas importante es ser conscientes que necesitamos cambiar, y tener la voluntad para hacerlo.

Estudios demuestran que el cerebro humano es moldeable incluso hasta la vejez. Lo que cambia es la facilidad con la que logramos interiorizar los patrones en nuestra vida conforme pasa el tiempo. La construcción mental de nuestras actividades diarias, mas que las actividades en si mismas determinan la forma como vemos el mundo. En torno a esto es importante encontrar un sentido, algo por que luchar y tratar de determinar como cada una de las cosas que hacemos en la vida aporta a este ideal. "Quien encuentra un ¿Por que? para vivir, casi siempre encuentra un como". Nietzshe

¿Y que puede ayudar a lograr el cambio?

  • Has lo que te gusta: Hablar con amigos, salir a pasear, ver una película. No podemos dejar pasar los mejores momentos de la vida haciendo lo que nos toca y no lo que nos gusta. 
  • Ayuda a alguien: Ayudar genera un sentimiento de placer que perdura varios días. Por algo la popular frase "Es mejor dar que recibir". No tienen que ser cosas materiales. Ayuda a un compañero de trabajo, escucha a alguien que este triste. 
  • Influye positivamente en tu alrededor: La forma como hablamos determina en gran parte lo que somos y lo que conseguimos. Nuestro actuar influencia positiva o negativamente nuestro alrededor. Estudios han demostrado que los empleados de jefes neuróticos y estresados tienden sentirse igual que su jefe y transmiten lo mismo a su circulo social. 
  • Ejercicio: El estrés, la tristeza, o cualquier otra emoción necesitan energía para perdurar, el ejercicio ayuda a quemar este exceso de energía reduciendo la intensidad de las reacciones químicas y a su vez ayuda a generar endorfinas produciendo un sentimiento de bienestar. 
  • Gasta tu dinero en experiencias no en cosas: Pasear, Salir con los amigos, disfrutar un café con la familia, hacer una fiesta o cualquier otra cosa que te permita tener buenos recuerdos.

2. The Fulcrum And The Lever

Arquimedes dijo. Dame un punto de apoyo y moveré el mundo.

Nuestro cerebro tiene un gran potencial y cada uno de nosotros decide como usarlo. Basta cambiar el punto de apoyo para lograr lo imposible. ¿Nuestra vida gira en torno a lo negativo?. Si es así tal vez el punto de apoyo este mal ubicado y no logremos desarrollar todo su potencial. ¿Por que?. Es genético: Cuando nos sentimos ante una situación peligro el cerebro limita la cantidad de opciones y por esta razón no podemos ver todas las posibilidades que tenemos en frente, si nos enfrentáramos a un tigre dientes de sable, no podemos darnos el lujo de analizar todas las alternativas y tomar la mejor decisión, por eso nuestro cerebro cumple su objetivo. Limitar las posibilidades. ¿Correr o Luchar? para poder mantenernos vivos. El problema es que en pleno siglo 21 debemos enfrentarnos a situaciones que aunque amenazantes requieren de toda nuestra capacidad mental y creatividad. Cuando vemos lo positivo en vez de solo lo negativo nuestro cerebro sale del estado de amenaza y nos permite ver todas las posibilidades a nuestro alrededor. Esto es llamado Anchoring.

Y esto no solo me afecta individualmente. También afecta a todas las personas que nos rodean. Lo que creemos determina en gran parte lo que logramos. Si creemos que una persona no va a poder hacer lo que se propone inconscientemente vamos a transmitirle siempre este mensaje y probablemente no lo logre. A esto se lo conoce como el efecto Pygmalion.Es normal sentir miedo, pero no debemos permitir que este nos inhabilite. Creo que incluso las personas que practican deportes extremos como Bungee Jumping lo sienten. Este es un estado natural y es imposible aislarlo. Pero aun así saltan. ¿Por que? Porque confían en el lazo que los sostiene y les garantiza que no van a morir golpeados contra las rocas. Al igual que la cuerda en este deporte, la confianza es nuestras propias capacidades es lo único que nos permite avanzar y vivir con tranquilidad. 


3. The Tetris Effect


Nuestro cerebro aprende a través de la repetición, por esto lo que logramos en la vida se ve muy influenciado por: Nuestra educación, Nuestra profesión y El entorno en el que nos movemos. Cuando hacemos algo por mucho tiempo, nuestro cerebro empieza a imitar estos patrones en otros escenarios, el nombre viene del clásico juego de tetris. 

Se hizo un experimento con un grupo de personas, éstas jugaron tetris durante varios días y al terminar empezaron a ver el mundo similar a este juego. Tratando de ubicar edificios en espacios libres o buscando patrones que pudieran encajar en los elementos de la vida diaria. Esto lo llevaron a la vida empresarial y descubrieron cosas como que los auditores están entrenados para encontrar errores en aquellos elementos que auditan. Pasan la mayor parte de sus vidas entrenándose para encontrar errores. Por esta razón desarrollan una increíble habilidad para ver lo malo pero les es muy difícil ver lo bueno.

Por esta razón la realidad no existe. Simplemente es una proyección que cada persona hace de lo que tiene a su alrededor (Positiva o Negativamente).

¿Por que pasa esto?. Nuestro cerebro internamente tiene un filtro que separa la información relevante de la que no lo es (Es su forma de mantenernos concentrados. Imaginen si fuésemos conscientes de cada hecho que surge en nuestra realidad en todo momento). El criterio de separación se crea a partir de los patrones mentales que gobiernan nuestra existencia. Por esta razón si somos negativos difícilmente vemos las cosas bellas y buenas que nos rodean.

Pero de la misma forma como se puede tener un efecto tetris negativo, se puede cambiar el patrón con conductas que promuevan lo contrario: Nuestras palabras son la principal herramienta para lograr esto. Al hablar positivamente alimentamos nuestro cerebro limbico y empezamos a generar conexiones que con el tiempo modificarán la forma como se filtra la información que recibimos del exterior y empezaremos a ver una realidad diferente.

Es importante aclarar que ser positivo no significa ser iluso. Las situaciones indeseadas no dejaran de serlo por si solas. Debo actuar para corregirlas y mantener la estabilidad en mi vida. De modo que ser positivo no se refiere al hecho de no ver la realidad de la vida. Se trata de verla con una percepción diferente y actuando en vez de preocupándose.

4. Falling Up


Tom Watson, expresidente de IBM decía "Si quieres tener éxito, duplica tu tasa de fracasos". Nuevamente se trata de un asunto de percepción. Si tengo una connotación negativa del error siempre tendré miedo de intentarlo, de probar nuevas formas de hacer las cosas y cuando fracase simplemente me quedaré ahí quejándome y esperando a que la vida se compadezca y me de otra oportunidad. 

Cuando tenemos una connotación negativa del fracaso tendemos a entrar en un estado de learned helplessness que con el tiempo nos lleva simplemente a no querer hacer nada para cambiar la situación por que nuestra concepción mental de la vida es: "Independiente de lo que haga el resultado será el mismo ¿Entonces para que hago algo?"

Cambia tu discurso y cambiarás lo que obtienes de la vida. Siempre existen mas opciones fuera de las evidentes.

5. The Zorro Circle


"At the beginning of the film The Mask of Zorro , we see him

as the young and impetuous Alejandro, whose passion far exceeds his patience and

discipline. His quest is to assail villains and right the injustices of the world, but he

desires to do so immediately and spectacularly. The higher he flies, the farther he falls,

until he soon feels out of control and utterly powerless. By the time the aging sword

master Don Diego meets him, Alejandro is a broken man, a slave to drinking and

despair. But Don Diego sees the young man’s potential and takes him under his wing,

promising Alejandro that mastery and triumph will come with “dedication and time.” In the

hidden cave that serves as Don Diego’s lair, the elder sword master begins Alejandro’s

training by drawing a circle in the dirt. Hour after hour, Alejandro is forced to fight only

within this small circle. As Don Diego wisely tells his protégé, “This circle will be your

world. Your whole life. Until I tell you otherwise, there is nothing outside of it.”

Once Alejandro masters control of this small circle, Don Diego allows him to slowly
attempt greater and greater feats, which, one by one, he achieves". Shawn achor

Como lo dice el viejo adagio: El que mucho abarca poco aprieta. Es importante tener metas alcanzables por nuestros propios medios. Querer la paz mundial puede ser un bonito ideal y en efecto una persona podría enfocarse en alcanzarla, pero: ¿Por si sola lo puede hacer? preocuparse por cosas que se salen de nuestro rango de acción solo trae impotencia y frustración.  Es importante identificar aquello en lo que vale realmente la pena enfocarse y en lo que se puede lograr resultados. El primer circulo de control debería ser "Yo". Si no puedo mejorar, generar cambios, lograr cosas conmigo mismo ¿Como puedo pretender hacerlo con los demás?. Cuando uno mejora el mundo a su alrededor se convierte en un mejor lugar. Normalmente las personas imitan lo que ven valioso para sus vidas.

Con el tiempo podré tener la confianza para ampliar el circulo y tener otros objetivos en el radar. Mis capacidades habrán mejorado y podré enfrentarme a nuevos retos de forma tranquila y serena.

En este punto Personal Kanban puede ser una herramienta de gran ayuda para mantener identificado y centrado nuestro circulo.

6. The 20 Second Rule


¿Por que aún cuando ver televisión no es una actividad que nos da mayor diversión preferimos hacerlo en vez de salir a pasear, a jugar o a hacer deporte?. Porque es mas fácil presionar el control remoto y tirarse en un sofá. 

Una buena forma de eliminar los malos hábitos es reducir la cantidad de energía necesaria para iniciar una buena acción. A esto se le llama la regla de los 20 segundos. Haga mas difícil ejecutar la mala acción que hacer la buena. Si quiere adquirir el habito de hacer deporte a diario, haga que le tome mas trabajo prender el televisor que salir a trotar. Podría sacar las baterías al control o en el caso extremo regalar el televisor :-). 

La regla de los 20 segundos no solo aplica para convertir las buenas acciones en hábitos positivos. También ayuda a eliminar los negativos. Por ejemplo si su problema en el trabajo es que el correo electrónico lo distrae constantemente. Haga que le tome mas de 20 segundos abrirlo (Elimine las contraseña guardadas, los historiales de navegación), obliguese a tener que ingresar toda la información cada que requiera acceder al correo. Con el tiempo se convertirá en un habito revisarlo solo en algunos espacios durante el día.

Los hábitos se conforman solo después de una serie de repeticiones, por esta razón no basta simplemente hacer deporte. Es importante hacerlo diario aunque sea en menor cantidad, esta es la única forma de convertirlo en habito. Punto en el cual incluso de forma inconsciente seguiremos haciéndolo.

7. Social Investment


Las personas mas felices y exitosas tiene  en común un gran circulo social. Irónicamente cuando tenemos problemas o estamos tristes lo primero que hacemos es aislarnos de la sociedad, encerrarnos en un cuarto y no querer recibir llamadas de nadie, aún cuando en estos momentos es mas importante tener el apoyo de las personas para salir de este estado mental. Por naturaleza somos seres sociables y necesitamos de los demás. 

Hoy pienso que la felicidad se logra cuando: Aceptamos el fracaso, no ponemos nuestros ideales de vida en bienes materiales como el dinero, tenemos sueños y encontramos la forma de enlazarlos a cada una de las cosas que hacemos, aprendemos del pasado e impedidos que este nos inhabilite, visualizamos el futuro que soñamos pero actuando en el presente y celebramos todo lo bueno que nos pasa en la vida con las personas que amamos.



martes, 22 de abril de 2014

Proceso e implementación de continous Performance testing

Introducción


Quienes están familiarizados con las prácticas de desarrollo ágil TDD, y ATDD habrán notado que estas se orientan principalmente a lo funcional descuidando un poco la verificación de los atributos de calidad del software, mas concretamente los requisitos de nivel de servicio. 

De hecho muchos equipos al hacer la transición al esquema ágil, delegan toda la responsabilidad de la calidad del producto a las pruebas unitarias y pruebas de aceptación, pues en este tipo de metodologías un área separada de aseguramiento de calidad pierde importancia al hacer de la calidad un preocupación de todos los miembros del equipo. El problema con este enfoque es que inicialmente no todos tenemos los skills necesarios para garantizar esto y con el tiempo la calidad de los productos construidos tiende a decrecer generando una mala percepción en los usuarios finales.

Si bien es importante mantener el concepto de calidad como responsabilidad compartida, es preciso también tener en cuenta otros aspectos que deben ser verificados para garantizar un producto de calidad.


Cuadrantes de testing ágil

A continuación quiero compartir con ustedes una forma para integrar las pruebas de desempeño dentro del ciclo de TDD y ATDD, lo cual nos llevará con el tiempo a hacer continous performance testing (Verificación constante del desempeño del aplicativo). Este se basa en los cuadrantes de testing ágil concepto inicialmente definido por  Brian Maricks.

Abstracción de alto nivel de un software


Abstracción de alto nivel de un software
Desde el punto de abstracción mas alto, un software se puede ver como un conjunto de UNIDADES FUNCIONALES (Probadas unitariamente), que en conjunto forman COMPONENTES DE SOFTWARE, los cuales a su vez constituyen FUNCIONALIDADES DE NEGOCIO. Las funcionalidades de negocio normalmente no conviven por si solas y requieren interactuar con sistemas externos para entregar el resultado final.

Consideraciones previas


Antes de entrar en la definición del proceso debemos tener claro que las pruebas de desempeño normalmente están asociadas a pruebas de estress (Alcanzar el punto de quiebre del sistema), y a pruebas de escalabilidad (Como se afecta el desempeño al incrementar la carga de usuarios concurrentes en el mismo). Probar estos aspectos requiere no solo herramientas adecuadas sino también recursos de hardware para poder generar la carga suficiente. Adicional a esto el tiempo de ejecución puede variar dependiendo de la maquina en la que se ejecuten las pruebas por lo que lograr un nivel de confiabilidad adecuado requiere que estas se ejecuten en ambientes muy similares a los productivos.

El proceso de pruebas de desempeño que se plantea en esta entrada plantea tres diferentes perspectivas que permitirán aumentar la confiabilidad en la verificación de los niveles de servicio de forma gradual.

ZZDNauswEIWfRssUWYHQLpM0TqEU2vQn3O4UaSyJyB4jyRfbTx85tilKQD/Md+CcmSHLbdnuHa/1G0qwhFHZkuUzYeyR0vgOoLsByhk5omwCjZHgExQQbTB1CgVWFYiQsAJtalZzBXfgU3B7T49GBj01x1Z//AWM0nNMtnoaFR+62UNCwRsbFlcUtUEu+ew1jdnSyWGqu5u65lXSUY9YJsCBN33adWHS6U/oJLgk1prqnK6tcXasdQjDRteE5fEoRGVBOvMfHkSMZrlGH+JHN734aItci+3rWv78ZoevzeG4b8//6HeUdz44HkAZHr0X8b67Bk7cDyOBK9CVvBJwjc7JcncB

  • Pruebas sobre COMPONENTE DE SOFTWARE sin integración externa: Al hacer esto verificamos que el código implementado sea potenciamente escalable (Si lo comparamos con el consumo de recursos), que tenga el throughput y los tiempos de respuesta que se requieren para cumplir con los niveles de servicio de la funcionalidad de negocio (Funcionalidad de negocio= Suma de los componentes). Las pruebas de performance son mas costosas de mantener en el tiempo respecto a las pruebas unitarias, por esto sugiero que no sean aplicadas a las unidades funcionales. 
  • Pruebas sobre COMPONENTE DE SOFTWARE con integración externa: Cuando existe dependencia con otros componentes de software las pruebas de vuelven incluso mas difíciles de mantener pues debemos lidiar con los datos. Por esta razón la cantidad de pruebas de este tipo que se realicen debe ser menor en comparación con la perspectiva anterior. Tenga en cuenta que al hacer este tipo de pruebas se debe garantizar que sean repetibles asegurando que los datos que se requieren como insumo se encuentren en el sistema externo y que los datos en los repositorios de información vuelvan al estado previo a la ejecución. Al realizar pruebas en esta perspectiva garantizamos que la integración con los sistemas externos sea adecuada
  • Pruebas de escalabilidad y estress sobre FUNCIONALIDAD DE NEGOCIO: Como ya lo mencioné probar escalabilidad y estress requieren recursos importantes de hardware y skills mas avanzados para lograr una verificación confiable. Por esta razón es importante que un equipo especializado las realice. Se puede utilizar la estrategia de Parallel independent Testing
Independiente de la perspectiva en la que se realicen las pruebas, es importante que estas puedan ser ejecutadas de forma automática por un servidor de integración continua y que se defina una linea base que permita ver como varia el desempeño en el tiempo al agregar mas funcionalidades o modificar el código existente.


Proceso


Las pruebas en las dos primeras perspectivas deben ser realizadas por el equipo de desarrollo, por esta razón se plantea el siguiente esquema en el que se integran las pruebas de performance dentro del ciclo ATDD.

La idea es que una vez se tenga construido un componente de software (En el ciclo TDD) y/o una funcionalidad de negocio (En el ciclo ATDD), se ejecute el ciclo interno de verificación del desempeño.

ZZHfa/sgFMX/Gh87rIGyPvbH0i+MPazrvmV7c3qjUuMtakbav76mMQwpyA1+DpxzriHVpu13np/1G0qwhFHZk2pLGHumNM0BXEYwXy6WI1HeyMwy6IyEUKCIaKM5l1CgcyBiwRq0pdmZK3gAH4LbR3o0Mupcly3++D8wSk8x86l2iJfJQ0LDOxtnd5S0QW755JUX7+l4ZTQbXDKYLaspyxWdrohtATwEcy17N6bc/we9BF8EW+NO5cN13o53HePwpivC6nQUorIgvfmFJ5GiWa0xxPSh66t475tai83rSv7/nu8P6/1x15++6GeSV4dtMktp6zQ36KJx2IVhIfAN+pY7AcM/hJAUda9Qk+rlBg==

Implementación


A continuación un vídeo que muestra paso a paso como implementar las pruebas en la primera perspectiva.