Archivo de la categoría: Productividad

Índice de emparramiento y problemas del multitasking

La sociedad de la información nos inunda con información desde todos los lados. Notificaciones de mensajes por whatsapp, actividad de tweeter, etiquetados en facebook, emails que llegan, artículos nuevos al blog que estas suscrito. Estamos acostumbrados a hacer como mínimo dos cosas a la vez, vemos la tele mientras navegamos, vemos las redes sociales mientras estamos en el trono, trabajamos con dos monitores para estar atento  a los emails mientras se está programando o escribiendo algún documento…

Estamos acostumbrados a trabajar en multitarea (o multitasking en inglés). Alardeamos de que podemos resolver varias incidencias o problemas a la vez. Sin embargo acostumbrarse a la multitarea tiene su lado negativo, no llegamos a establecer concentración plena en ninguna de las tareas que tenemos delante. El tener capacidad de multitasking nos permite cambiar de una a otra sin problemas pero no llegamos a usar nuestro pleno potencial en ninguna de ellas.

El multitasking no sólo afecta al trabajo. El navegar mentalmente de un tema a otro nos hace vivir el día a día en modo automático mientras pensamos en cómo resolver ese problema del trabajo, en que hay que llevar el coche al taller,  en que queda poco dinero en la cuenta, que la próxima semana hay que ir a la reunión del niño, las cosas que quieres hacer el siguiente mes, etc, etc, etc y… etc.

Yo soy una víctima de ello. Pensaba que mi navegación mental era una aptitud que me permitía encontrar soluciones a las que nadie más llegaba. Esto hasta que me di cuenta que había perdido el control del timón. Esta perdida de concentración estaba afectando a mi trabajo y a mi vida fuera de él.

Leyendo este hallazgo sobre “The Effects of Mindfulness Meditation Training on Multitasking in a
High-Stress Information Environment” encontré este test. Te mide el índice de atención plena que sería lo contrario al índice de emparramiento, que es la capacidad de “estar en la parra”, con la mente en otro lado distinto al presente.

Sólo ver el test, si eres de los mios, te sentirás identificado. Tranquilo, parece que hay solución al problema. Se llama Mindfulness. Es un modo de meditación en la que solamente hay que centrarse en la respiración o en las sensaciones del propio cuerpo. Solamente existe el presente y uno mismo. Cualquier pensamiento ajeno hay que descartarlo y volver al presente. Iré contando resultados.

¿Está TDD muerto? Resumen del videodebate

Mientras hacen subtitulos para el Hangout entre David Heinemeier Hansson, Kent Beck y Martin Fowler, voy a escribir un poco lo que han hablado para que los que no entiendan el inglés, o no tienen los 30 minutos para verlo entero, puedan quedarse con las claves. En mi anterior artículo hablo de los artículos y tweets que empezaron la discusión.

El link al video es éste.

Empieza David hablando de los 3 problemas que ve al TDD: la insistencia en que los tests tienen que correr en milisegundos, que termina creando un diseño feo y complejo y que el bucle de rojo-verde-refactor es poco natural para el programador.

Kent cuenta que el TDD le da la confianza que necesita a la hora de dar un desarrollo por completado y funcionando. Sin TDD, uno se va a casa sin la seguridad de que el código que ha escrito funcione bien. Además le ayuda a pensar primero en el problema. Cuando no se tienen especificaciones concretas TDD sirve para empezar de lo más concreto (ejemplos en los tests) a la implementación más genérica.

David entiende en que Kent piense en la seguridad como un factor de felicidad del programador. Él mismo dice que le da prioridad a la felicidad del programador cuando empezó Ruby on Rails. Sin embargo, la seguridad de que todo va a funcionar es sólo un factor de felicidad del programador pero hay otros. El tener que cambiar el flujo de pensamiento a pensar primero el test antes de empezar lo ve como una forma de confundir al programador y no dejarle crear del modo que le es más natural. Además dice que la seguridad de que el código funciona no debería venir unicamente del TDD

Ante un ejemplo reciente de Kent sobre un uso idoneo del TDD, David responde que en los desarrollos que él hace no es normal tener un código tan aislado como el que Kent comenta. Que para poder conseguir un codigo perfecto testeable típico de un input consigue un output tiene que separar capas y capas y crear muchos mocks. Que tiene que hacer un gran sacrificio para conseguir ese código perfecto para TDD.

Kent afirma que en todo esto tiene que haber un balance. Hay que tener en cuenta el coste de aislarlo todo para testearlo de manera independiente y su beneficio. Que no hace falta hacer mocks de todo. Si tienes unos tests de objetos que usan otros objetos reales o un sistema real y se es capaz de tener así la prueba de si va o no va, es suficiente. Cuenta que mucha gente se queja de que el Unit Test no le deja refactorizar. Esto ocurre porque sus tests complejos que tienen mocks que devuelven mocks y como fruto estos tests están muy acoplados a la implementación.

Segun David, el problema está en la definicion de TDD segun algunos sectores del desarrollo. Estos sectores afirman cosas como que cualquier test tiene que estar basado en mocks y que si no usas TDD no eres buen profesional. Incluso que si el diseño del programa no está dirigido por tests, no es buen diseño. Para David es al contrario, TDD fuerza a tener un diseño no natural.

Martin Fowler, quedandose un poco en medio y actuando un poco como arbitro del debate, también dando su opinión más pragmática. Dice que hay en la calle muchas definiciones de TDD. Algunas de ellas dicen que todo tiene que estar con mocks. Sin embargo la realidad es que si no usa mocks y el test es util, perfecto. Dice que el TDD y el Unit test son dos cosas aisladas y hay que tratarlas como tal. Se puede hacer TDD sin que todo el codigo testeado esté aislado. Para él, como ya dijo en su artículo, lo importante es que el código sea autotesteable, que haya un botón que pueda probar todo el código. TDD está bien porque ofrece esto como uno de sus beneficios.  Está de acuerdo en que en ocasiones no se puede usar TDD, cosa que le apena ya que dice que es una herramienta que le gusta. También opina que incluso hay que separar conceptualmente el Unit testing aislado y el no aislado.

El debate termina barajando un posible futuro debate hablando unicamente de si el TDD crea un buen diseño o no.

 

 

 

Motores, lastres y minas en retrospectivas

¿Cuánto tiempo tardas en ir de casa al trabajo? Normalmente ese tiempo varía un poco cada día. Por ejemplo un día tardas 20 minutos, otro 23, otro 19, 20,… Esa variación de tiempo que ya tienes asumida se llama “Variación de causa común“. Ahora piensa en la última vez que llegaste tarde. Pudo ser por un problema de tráfico, tu hijo estaba enfermo y hubo que llevarlo a casa de la abuela… Esa vez tardaste 40 minutos. Ese tipo de variación se llama “Variación de causa asignable“. Es asignable porque puedes asignarle una razón (o una excusa).

En VSN trabajamos desde hace unos meses  la retrospectiva con la analogía de la lancha. El equipo es una lancha en la que los motores representan aquellas cosas que nos hacen ir rápidos y con calidad.  Los lastres atados son las cosas que nos hacen ir más lentos. Desde hoy tenemos un elemento nuevo. Ahora identificamos también las minas con las que se encuentra esta lancha por el camino. Estas minas representan esos problemas de causa asignable, esos problemas ocasionales que han ocurrido y pueden volver a ocurrir, o no.

20140411_145919_pq

Cuando trabajamos estas retrospectivas, el equipo escribe en los Post-It amarillos los elementos a destacar del sprint: los motores, los lastres y ahora las minas. Una vez están todas las etiquetas en la pizarra las organizamos juntando las comunes y las analizamos. Primero buscamos soluciones para los lastres, después confirmamos que los motores que tenemos siguen siendo útiles y debemos seguir usandolos y por último analizamos las minas para ver cómo actuar cuando nos las volvamos a encontrar.

Primero indicamos la posibilidad de encontrarnosla. Podría ser eventual, esto quiere decir que el problema ha ocurrido y ya está, que es raro que vuelva a ocurrir.Podría ser frecuente, una vez cada sprint o cada pocos sprints. Si es un problema constante lo más normal es que se encuentre en la parte de lastres.  Despues recordamos el efecto que ha causado en el equipo. En qué nos ha afectado. Ha sido una molestia o ha sido un gran trauma. Por último definimos el plan de defensa, qué hacer con la mina la próxima vez que nos la encontremos. Aquí tenemos 3 opciones:

  1. Preparar contramedida para destruir la mina la próxima vez. Se piensa cómo eliminar el riesgo para que no vuelva a afectar lo más mínimo al equipo.
  2. Mitigar el daño cuando ocurra el choque. Podría ser que lo mejor es que cuando el problema ocurra de nuevo estar preparado para que afecte lo menos posible.
  3. Ignorar la mina. Cerrar los ojos, apretar el culo y sencillamente aceptarla tal cual llega. Esto se decide así cuando las consecuencias de tener un plan de acción podrían sobrepasan el efecto de la propia mina.

Los planes que se hacen con las minas las vamos a recoger en un documento accesible por todo el equipo. Cuando en un análisis de sprint, de historia o en algún Daily asome la sospecha de que se nos acerca una mina conocida, sabremos cómo actuar. Con esta sencilla analogía de las minas vamos a tener  lo que se llama en gestión de proyectos tradicional, Gestión de Riesgos. Sin embargo lo hacemos de una manera Ágil. Primero porque lo hace el propio equipo y segundo porque se minimiza el tiempo gestionando este nuevo artefacto respecto a la mejora en el equipo que esperamos que produzca.

Cuando el manager se convierte en un lastre para el equipo

En nuestro equipo de desarrollo hacemos una retrospectiva al final de cada sprint (como se debe). Nosotros usamos la técnica del barco. Dibujo un barco en la pizarra con un espacio de motores que simboliza los lo que nos hace ir a buena velocidad y unos lastres atados que simboliza problemas que nos dificultan ir a mayor velocidad.

En la retrospectiva anterior que celebramos ocurrió algo que no había pasado y el que ocurriera me llenó de orgullo. Me dijeron que YO era un lastre cuando tocaba código de producción. Ocurrió que para intentar hacer una historia de usuario que parecía que no iba a entrar decidí hacerla yo por mi cuenta. Al final produjo unos problemas que les hizo perder el tiempo arreglándolo 😛

Por un lado, como me gusta tanto programar fue en parte una lástima pero como facilitador de equipo me encantó. De hecho di las gracias personalmente después de la reunión a quien me lo dijo y explico por qué.

1.- Decir algo así a quien en principio “es tu jefe” requiere cierto grado de valentía. No debe ser fácil. Por lo tanto veo que hay CONFIANZA por su parte.
2.- Yo, que me esfuerzo en que el equipo vaya cada vez más rápido y con mejor calidad, si en lugar de tener que hacer algo para ello tengo que dejar de hacerlo, para mi es más sencillo.
3.-  Me hace ver que hay el clima de sinceridad en las retrospectivas que es muy necesario para mejorar sprint tras sprint.

Por lo tanto, no tengáis miedo si un día os dicen que habéis hecho algo que se considera un lastre para el equipo, u os habéis equivocado. Es el mejor indicador de que el trabajo de uno es importante y que el resto de cosas se hacen bien, ya que si no fuera así alguien se lo diría para mejorarlo.

Preguntas que tal vez te hagas de los Coderetreats

Apuntaros esta fecha todos los desarrolladores: Sábado 14 de Diciembre del 2013. Ese día se celebra en distintas ciudades de todo el mundo el Día Global del Coderetreat.

“¿Y qué es esta frikada?” Esta frikada es una oportunidad única de aprender a mejorar la calidad personal del desarrollo de software.

“Pero yo ya programo mucho en el trabajo”. Sí, pero cuando se trabaja la atención está en acabar lo antes posible. Normalmente se programa del modo que se cree más rápido sin intentar buscar nuevas maneras de hacerlo. Haciendo un kata, como el del Juego de la Vida que es el que se suele hacer ese día, te puedes permitir el lujo de hacerlo de esa forma que has leído u oídopero que nunca te habías atrevido a probar. El objetivo NO es terminar el kata. De hecho, a los 45 minutos tienes que borrar el código que has hecho.

“¿Queeee?, ¿Borrar lo que he hecho?” Cierto. Cada 45 minutos vas a enfrentarte al problema desde distintos ángulos y con determinadas restricciones que van cambiando.

“¿Y crees entonces que aprenderé algo?” Ciertamente. Mejorarás estas habilidades:

TDD: +4 Todas las sesiones se realizan haciendo primero los tests y después la solución.
Código limpio: +3 El foco constante está en trabajar con ese código ideal que nunca te has atrevido a escribir por falta de tiempo
Programación en parejas: +3 Todas las sesiones son en pareja mediante el método de PingPong. Uno escribe el test y hace que falla, el otro lo desarrolla,lo pasa a verde y escribe el test para el otro miembro.
Otros lenguajes: 30% de probabildades En cada sesión podrás trabajar con otros que usan otros lenguajes de programación como su segunda lengua madre
Carisma: +2 Trabajar codo con codo con gente con la que nunca has trabajado servirá para mejorar tus habilidades sociales en el trabajo.

“¿Dónde me puedo apuntar a uno?” En España se están haciendo en varios lugares. Aquí tienes una lista

Alicante http://tinyurl.com/on39bq4
Barcelona http://agile-barcelona.org
Caceres http://tinyurl.com/p52qq3d
Madrid http://tinyurl.com/p884qtw
Ourense http://tinyurl.com/on72tsj
Valencia http://tinyurl.com/q3yyj5d
Zaragoza http://tinyurl.com/pa7xp6r

Para buscar en otros lugares del mundo puedes buscarlo aquí: http://coderetreat.org/events

Date prisa. Normalmente las plazas son limitadas.

Si te pica el gusanillo aquí puedes ver más información de los amigos de Agile Madrid. madridcoderetreat.wordpress.com

Si tienes una empresa o conoces alguna que esté dispuesta a patrocinar algo de estas sesiones. Todos los participantes estarán muy agradecidos de que por ejemplo traiga la comida del día o de algun regalo o alguna licencia de software. Animará mucho el día y todos los asistentes tendrán en muy buena imagen la empresa. Contacta con el organizador de la sesión y preguntale qué necesita si estas interesado.

Enfermería, Desarrollo de Software y Servant Leadership

La ingeniería informática es una profesión joven. Algunos nos orgullecemos de haber empezado hace 25 años con los MSXs y su BASIC. Otros empezaron su profesión con las tarjetas perforadas y sin poder preguntar en aquel entonces a nadie cualquier problema técnico que pudieran encontrar (Oh! Bendito Stackoverflow!)

La medicina, por el contrario,  es una de las profesiones técnicas más antiguas. Desde los antiguos chamanes, pasando por el árabe Avicena (Ali Ibn Cina) a las modernas clínicas y hospitales.  Florence Nightingale, a finales del siglo 19 hizo un gran avance en la medicina separando responsabilidades y posibilitando que enfermeras, entrenadas por ella misma, liberaran a los saturados médicos en las curas sencillas de la Guerra de Crimea mejorando su recuperación. Desde ese momento, mucho ha llovido en en el mundo de la enfermería y han adquirido muchos, diversos y muy importantes roles.

Un ejemplo claro de su importante labor es la de las auxiliares en las consultas médicas. Las ves entrando y saliendo de las consultas, recibiendo llamadas, llamando a pacientes,… Tengo la suerte de estar casado con una de ellas y desde hace poco me he dado cuenta de la similitud de lo que hace con mi trabajo como director de desarrollo. Paso a citar algunas de las cosas que hacen:

  • Preparan todo el material y documentación para que los médicos puedan hacer más productivo el tiempo que pasan con el paciente
  • Bloquean las interrupciones (comerciales, llamadas, preguntas,..) para que se puedan centrar en el paciente hasta que termina la consulta
  • Gestionar prioridades. Dan respuesta personales a los pacientes citándolos según la urgencia de sus problemas.
  • Reducir el Lead Time (Tiempo de Entrega). Citan a los pacientes para analíticas, pruebas de anestesia, cirugía,.. de tal modo que el paciente pase el menor tiempo posible desde que empieza el proceso hasta que termina y sea más rápido y menos traumático.

Esa función en los equipos de desarrollo la tienen los Scrum Masters/Team Leaders/Directores de Desarrollo/Whatever…. Ambos nos ocupamos en que nuestro  equipo (médicos o desarrolladores) sean lo más productivos posible con su tiempo. Los papeles y herramientas de trabajo más importantes tienen que estar en estado READY para que puedan trabajar sin interrupciones y sin que tengan que ocupar su tiempo en algo que puede hacer otra persona. Ambos podemos hacer que la productividad de un equipo aumente o disminuya drásticamente según lo bien o mal que lo hagamos. En gestión de proyectos Ágiles lo llamamos Servant Leadership como si fuera un concepto nuevo pero es algo que lo llevan haciendo hace tiempo las auxiliares, sin tanto bombo y platillo y conceptos en inglés.

La próxima vez que este esperando a entrar al medico fíjate en ellas, las auxiliares o enfermeras, quizá aprendas algo de cómo mejorar la productividad de tu equipo de desarrollo.

Potencia tus reuniones

Llega un momento en la evolución de un equipo de trabajo que empieza a ver las reuniones como el siguiente punto de mejora. Problemas comunes son reuniones que se alargan más de lo debido y falta de conclusiones. Para evitar estos problemas existen una serie de técnicas que conviene utilizar.

1.- Establecer un objetivo claro para la reunión. Cuanto más concreto sea el objetivo mejor. Si hay varios, al principio de la misma debería hacerse un listado de todo lo que se pretende hablar en la reunión y de lo que se tratará en otras.

2.- Intentar que el tema esté preparado con anterioridad. Todo lo que se pueda llevar ya pensado a la reunión será tiempo que se ahorre por parte de todos en la misma. Todos los miembros deberían entender el alcance del problema lo suficiente para que en la misma se vaya directamente a comentar y elegir las soluciones.

3.- Asignar un tiempo máximo y asegurar que sea visible el tiempo restante una vez empezada la reunión. Son muy útiles los relojes web (http://www.online-stopwatch.com/)o alguno de cocina con los números grandes como éste. El ser conscientes del tiempo limitado hace que todos los miembros estén más enfocados en el objetivo de la reunión.

4.- Apuntar los temas paralelos que surjan durante la reunión y tratarlos en otro momento. No cambiar de tema a mitad de la reunión. Esto se acerca mucho a lo que apunta la técnica pomodoro. Si surgen temas nuevos hay que apuntarlos para hablar de ello al terminar  o en otra reunión. El tiempo asignado sólo debería ser para el tema que teníais programado.

5.- Usar toda los elementos visuales que se pueda. Pizarras, dibujos en papel, ver el software en una pantalla grande,…. Visualizar todos a la vez el problema y las posibles soluciones ayuda a definir soluciones más simples y más rapidamente.

6.- Cuando se vaya a terminar la reunión hacer  conclusiones y asegurarse que se apuntan correctamente. Es util tener un secretario que apunte las tareas en papel o en un sistema digital pero debe ser un sistema en el que se pueda añadir de manera rápida las conclusiones.

7.- No pasa nada porque al principio se pase algo del tiempo asignado. El timeboxing de las reuniones es algo que se consigue hacer bien con la práctica. Los sprints de scrum tambien cuesta bastantes iteraciones el ajustarse al tiempo establecido.

Maldita la empresa de software que necesita heroes

Esta frase surgio en mi cabeza cuando vi en una libreria la portada del libro “Maldito el pais que necesita heroes” . Sé que hablo de heroes completamente distintos que los que seguramente hable el libro. Cuando hablo de heroes me refiero a esas personas que salvan el mundo cada día terminando de configurar un servidor hasta las 3 de la madrugada. Tú también los conoces, quizá tu también seas un heroe. Llegan por la mañana al día siguiente vestido de Clark Kent  recordando cómo a última hora encontró con la solución que permite que la empresa sigue siendo la que es. En sus adentros espera que el menos su jefe se entere de esta heoricidad y que a su pareja se le pase pronto el enfado por haber cancelado la cena que tenían preparada.

Source: http://blog.aimvic.com.au/2012/07/02/leon-gettler-coping-with-burnout/

Hay empresas en las que estas heoricidades son cosa de día a día. Sin embargo, precisamente en el considerarlo normal radica el problema. Una heroicididad normalmente es un Failure Demand o Failure Load ya que es trabajo provocado por un error que nunca debería haber ocurrido.  Se gastan recursos fisicos, mentales, personales y de otros muchos tipos para resolver estos tipos de problemas. Muchas veces los trabajadores acaban quemados por este tipo de heroicidades y acaban por irse. Este hecho,  además del problema en sí de que un compañero se vaya, es la perdida de productividad de la empresa mientras que la persona que lo sustituye alcaza su nivel de formación. Esta formación tambien implica unos costes economicos de la empresa que no hay que despreciar.

Es importante para el manager eliminar la necesidad de heros. Para ello es necesario que todas las heroicidades sean registradas y en retrospectivas o en reuniones de dirección se piense como evitar que vuelva a ocurrir el mismo problema. Si se sigue esto poco a poco debería verse menos gente con la S de Superman y ojeras en los ojos y más gente motivada que le gusta su trabajo.