Optimiza el uso de tu memoria (mental)

¿Cuantas cosas sabes hacer a la vez? ¿y hacerlas realmente bien? ¿Y además en un tiempo aceptable? Antes de responder a estas preguntas, me gustaría que conocieras cómo funciona nuestra mente.

El cerebro está compuesto de bloques de memoria de cortisimo plazo o de trabajo, de corto plazo y de largo plazo. Cuando realizamos un trabajo utilizamos una combinación de todos estos bloques a la vez. Por ejemplo, un desarrollador de software necesita tener en la mente el lenguaje de programación a usar, el diagrama conceptual del proyecto que está modificando, el objetivo de la funcionalidad que está desarrollando y en la zona de cortísimo plazo el algoritmo que se está escribiendo en ese momento. Un ingeniero de soporte puede tener el sistema del cliente, los detalles del problema en cuestión y el producto del cual está dando soporte. Un comercial puede tener detalles del producto que vende y detalles del cliente al que quiere vender.

Bloques de memoria de un desarrollador concentrado
Bloques de memoria de un desarrollador concentrado

Contínuamente tenemos que reemplazar estos bloques. Esto puede ser  por una interrupción que provoca un cambio de contexto y necesitas modificar tu memoria de más corto plazo. Pero también puede ser cuando cambias a desarrollar otro programa, otra historia de usuario u otra funcionalidad, incluso por un cambio de lenguaje de programación. Cada cambio requiere que uno o más bloques de memoria se reemplacen. Y ese reemplazo tarda tiempo. Si es memoria a corto plazo puede tardar incluso más de 15 minutos pero si es memoria de medio plazo como el lenguaje de programación se puede tardar días en sustituirlo completamente.

Cambio de tarea en otro lenguaje de programación
Cambio de tarea en otro lenguaje de programación

Hasta que un bloque es completamente sustituido, el bloque tiene una mezcla de distintos contenidos. Es el momento en el cual se toman decisiones incorrectas y se cometen fallos. Es cuando lo justificamos a que no estamos completamente concentrado y se producen frustraciones.

Para tomar mejores decisiones, realizar un trabajo de mejor calidad y más rápido hay que reducir el WIP. WIP significa trabajo en curso (Work In Progress) y hay que intentar que como máximo se tenga una tarea en la cabeza,  o una característica nueva a la vez por equipo, o una incidencia de soporte a la vez. Ya existen herramientas como Kanban, GTD y la Técnica Pomodoro para ayudarte a enfocarte en una tarea o con un mínimo de trabajo a la vez. Pero ninguna de estas técnicas ayuda a decidir con qué tareas ponerse o qué trabajo empezar una vez se ha terminado para minimizar el reemplazo de la memoria de trabajo.

Para ello propongo hacer una lista de los 5  elementos que más se tienen en cuenta a la hora de realizar una tarea . En el ejemplo del desarrollador de sofware, haríamos esta lista:

  • El tipo de tarea a hacer: desarrollo, administrativo (emails, imputar,…) , test, formación…
  • El lenguaje de desarrollo a usar
  • La estructura del programa a modificar
  • El framework o API que se usa: ASPNET MVC, Backbone, Angular,…
  • Las características del cliente que usará la funcionalidad

Para cada característica distinta a la de la tarea que se ha terminado se suma un punto. Si hacemos un tipo de tarea completamente distinta tendríamos 5 puntos porque seguramente necesita reemplazar todos los bloques de memoria. Si es del mismo programa pero hay que cambiar de lenguaje es un punto por el cambio de lenguaje y seguramente otro por el cambio de framework llegando a 2 puntos. Cada vez que se elige una nueva tarea hay que evaluar los puntos de lo que podemos empezar dentro de las que tengan igual prioridad. Idealmente se elegirá una tarea del mismo lenguajes, del mismo programa, con el mismo framework y para el mismo cliente. De este modo reducimos el número de bloques de memoria a reemplazar consiguiendo un resultado con mejor calidad, en menor tiempo y sin frustraciones.

 

Cómo el stress afecta a la calidad del software

El uso de las metodologías ágiles en el desarrollo de software ha supuesto un antes y un después en relación a la calidad de los productos. Webs, aplicaciones, juegos, son cada vez más elaborados, imaginativos y más seguros.

Uno de los principios ágiles habla de ritmo sostenible (sustainable pace). La interpretación más aceptada es la de jornadas de trabajo de 40 horas semanales. Está más que demostrado empíricamente que las horas extras en desarrollo de software está linealmente relacionado con un incremento en los bugs cometidos.

Bien, pues aquí tenemos la razón.  La culpa la tiene el stress.

El stress envía hormonas a la sangre para preparar al cuerpo y la mente para la situación amenazante. Durante miles de años, para los humanos, las situaciones amenazantes tenían que ver con peligros físicos de animales depredadores, posibles accidentes o peleas entre tribus y estas sustancias preparaban al cuerpo para afrontarlas. Sin embargo en la época de la información y para trabajadores del conocimiento tienen precisamente el efecto contrario.

Estas dos simpáticas hormonas son la famosa adrenalina, que produce un incremento en el ritmo cardíaco, la presión de sangre y la respiración; y glucocorticoides como el cortisol. Bueno, pues estos últimos producen entre otros, unos efectos muy perjudiciales a la memoria de corto plazo y la memoria de trabajo.

La memoria de trabajo es la parte del cerebro en la que almacena los datos que tenemos que combinar, comparar y analizar para resolver los problemas. Nuestra memoria RAM. Tipicamente un cerebro  normal mantiene y trabaja con 7+-2 chunks o bloques de datos simultáneamente para resolver los problemas. Los glucocorticoides reducen este número por lo que la mente se ve limitada a trabajar con menos datos y menos alternativas para intentar resolver ese diseño o ese código que hay que hacer que funcione.

Los militares han hecho muchos estudios relacionados con la reacción de las personas en situaciones de stress (ver referencias). En un estudio se demostró que el stress tenía el efecto positivo de reducir el tiempo de reacción, sin embargo esto tenía el efecto colateral de crear un mayor número de falsas alarmas y errores que las surgidas en condiciones de tranquilidad. Es decir, estresados fallamos más que una escopeta de feria. Mantenemos nuestra atención en la parte negativa del problema para intentar resolverla lo cual nos impide mirarlo desde fuera, afrontarlo lateralmente para poder ver otros ángulos y encontrar mejores soluciones.

En otro estudio se demostró que las personas, en situaciones de stress experimentamos una percepción superficial de la realidad, poniendo nuestra atención sólo a una pequeña parcela del problema a la hora de tomar una decisión o encontrar una solución. En este estado de alta tensión tomamos decisiones basadas en un conjunto incompleto de información y tomamos atajos basados en experiencias pasadas.

En resumen, tenemos que un desarrollador o u trabajador en general cuando está estresado reduce  su memoria de trabajo, no es capaz de tener visión lateral y creativa y toma atajos para resolver el problema lo más rápidamente posible sin pensar en más allá que el alcance de su problema… Conseguimos al DESARROLLADOR BOMBA. Preparaos para bugs por doquier, deuda técnica acumulandose, software de baja calidad y clientes decepcionados.

Todo esto se puede evitar manteniendo el ritmo de trabajo a un ritmo mantenible. Respetando la capacidad del departamento de desarrollo mediante sistema PULL con Kanban o de compromiso de equipo en el  sprint de Scrum. Respetando la definición de DONE sin saltarse por la presión y manteniendo un ambiente de trabajo animado y relajado. Todo esto no debe ser un lujo, sino un requerimiento.

 

 

 

 

 

 

 

 

 

 

Referencias

 

http://en.wikipedia.org/wiki/Effects_of_stress_on_memory

http://en.wikipedia.org/wiki/Short-term_memory

http://en.wikipedia.org/wiki/Working_memory

http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two

http://the-programmers-stone.com/wp-content/uploads/2007/10/StressAndPerformance.pdf

http://www.researchgate.net/publication/259781769_Impact_of_Overtime_and_Stress_on_Software_Quality

¿Le compramos un I5 ó un I7 al nuevo desarrollador?

Quizá alguna vez te has visto envuelto en una discusión parecida. Entra un desarrollador nuevo o hay que renovar el ordenador de uno de los desarrolladores y toca pedir uno. Entonces la persona encargada de compras puede intentar ahorrar y puede preguntar cosas como “¿Con un I5 es suficiente, no?”

Voy a intentar explicar un poco por qué es muy peligroso ahorrar en cosas de este tipo:

Imaginemos una empresa de desarrollo normal, una PYME, con unos gastos medios de 100.000 € al mes. Este gasto incluye equipo de comerciales, administración, marketing, operaciones y por supuesto desarrollo.Incluye tanto gastos en personal como gastos de instalaciónes y gestión. La cantidad de pasta que necesita la empresa para producir y vender  su producto, en nuestro caso software, son 100.000 euros mensuales.

Captura de pantalla 2014-11-01 a las 23.18.00

 

Ahora vamos a pensar en qué departamento es el cuello de botella, es decir, qué equipo es el que determina qué cantidad de producto llega al cliente final. Lo normal en una empresa de desarrollo de software que va más o menos bien es que el cuello de botella sea el equipo de desarrollo. Si se desarrolla más rápido cuando se tiene un proyecto para un cliente, se cobrará antes y se podrá empezar antes con otro proyecto. Si se desarrolla producto, contando con una buena elección de producto y características, se cuenta con que cuanto más se desarrolle, mejor es el producto y más vende.

Captura de pantalla 2014-11-01 a las 23.30.26

La Teoría de las Restricciones nos dice que la productividad total de una empresa está limitada por la productividad del cuello de botella. Si el cuello de botella, en nuestro caso el departamento de desarrollo, incrementa un 1% su productividad, es la empresa completa la que incrementa su productividad un 1%. Lo mismo ocurre al contrario, si la productividad decrece un 1%, es la productividad de la empresa al completo la que decrece.

Teniendo en cuenta que para conseguir esa productividad, esa cantidad de producto vendido al cliente, la empresa gasta 100.000 € al mes, es lógico pensar que cada 1% de productividad le cuesta 1.000€ al mes a las arcas. Un 1% de productividad perdido por una herramienta de bajo coste, en nuestro caso un ordenador barato, alargada por la vida útil del mismo, digamos 2 años, resulta en 12.000€ de productividad perdidos. Todo por haber comprado un portátil de 400€ del Media Markt.

Después detodo esto…,  ¿Empezamos a hablar de discos duros SSD?

Wastes o desperdicios en desarrollo de software

Me he propuesto hacer el ejercicio de identificar qué desperdicio Lean está asociado a cada lastre de una retrospectiva y cual se elimina o reduce en cada motor. Para saber de qué estoy hablando con motores y lastres entra aquí

Para que no vayas buscando en la wiki o páginas aparte cada lastre voy a resumir cuales son los 7 +1 wastes en desarrollo de software

1. Esperas. Esperas por recibir un detalle de un requerimiento, esperas para tener un build completo, esperas a que se completen los tests, esperas hasta que lo que has desarrollado lo prueba el cliente y te dice si es lo que quería, esperas a que un compañero te resuelva una pregunta que no te deja continuar…

2. Sobreproducción. Hacer programas que nadie necesita y nadie usará nunca.

3. Sobreingeniería. Es parecido al anterior. Desarrollar funcionalidades que no se han pedido sólo por aprovechar el tiempo en algo. Por ejemplo, preparar un sistema para millones de usuarios cuando es una panadería local.

4. Stock. Sí, en desarrollo también existe el stock. Stock de análisis de historias que nunca llegan a desarrollarse, stock de desarrollo que nunca se completa o se prueba, stock de funcionalidades que nunca llegan a deploy. Cada uno de estos stocks ocupan espacio en complejidad, y hace más difícil nuevos desarrollos sin que haya dado valor.

5. Transporte. En desarrollo de software el transporte está relacionado con el cambio de contexto. Cada vez que tienes que pasar contenido de la memoria a largo plazo a  la de corto plazo hay trasaporte. Ejemplos son cambios de historias en el mismo día, cambios de lenguajes de programación, cambios de rol del programador.

6. Movimiento. Es movimiento de personas tanto en espacio físico (para preguntar, pasar a otro ordenador, etc..) como movimientos virtuales (entrar en una ruta de directorios compleja, muchos clics para resolver un problema o hacer una acción)

7. Defectos. No creo que haya discusión en esto. Cualquier defecto en diseño, desarrollo o test provoca trabajo extra. Cuanto más se retrasa el momento del defecto a su descubrimiento y resolución, mayor suele ser ese trabajo extra o coste.

y el +1. Talento. Cada vez que uno realiza un trabajo que puede hacer otro, desaprovechando el talento o conocimientos que nadie más tiene, es un desperdicio.  Muchas veces ocurre por aliviar un cuello de botella pero hay que evaluar el sobrecoste de ese desperdicio de talento para buscar otras formas de gestionarlo.

Antipatrón, midiendo el esfuerzo

<ironic>

Es muy dificil encontrar una métrica que evalúe el rendimiento de los miembros del equipo por separado. Cualquier libro moderno de gestión de personas recomienda evaluar al equipo globalmente pero nosotros, los buenos jefes de equipo, tenemos que recompensar a los que se están dejando el pellejo y localizar a los que no tienen suficiente compromiso con el proyecto.

Una cosa que hacemos bien en España, y por eso somos de los países más competitivos, es nuestra orientación al esfuerzo. Si no dedicamos mil horas diarias a algo y nos dejamos hasta la ultima gota de energía de nuestro cuerpo, un trabajo no está bien hecho. Otros países “más modernos” prefieren buscar formas de hacer el trabajo más comodamente… ¡Nenazas!

El esfuerzo es algo muy dificil de medir. Lamentablemente, las leyes de privacidad nos impiden usar electrocardiogramas en los trabajadores. Con ellas podríamos obtener de manera muy fiable el ritmo de trabajo de cada uno.

Afortunadamente hay otras formas más legales:

Medidor de sudor. Es una sencilla banda adhesiva que se pone en la frente de los trabajadores. Esta banda tiene un pequeño chip y un emisor bluetooth. La banda obtiene el nivel de sudoración en tiempo real y lo envía al servidor central. Cada día los trabajadores tienen que cambiar la banda adhesiva ya que queda (debería quedar) llena de sudor. Es importante tener consumibles  disponibles para que no haya trabajador sin banda. El único problema es que  cada persona sudora de manera distinta y el dispositivo es difícil de calibrar.

Medidor de sudor
Medidor de sudor

Dinamómetro de nalgas. Este es el más fiable  Es un sencillo dispositivo que se coloca entre las nalgas de cada trabajador. Mide la presión ejercida durante el trabajo por su parte trasera y se envía igualmente por bluetooth. A más presión recibida, mayor esfuerzo es el que está efectuando el trabajador. El dinamómetro es personal y cada trabajador debe ser responsable de su limpieza diaria.

Dinamometro de nalgas
Dinamometro de nalgas

Los datos recibidos del esfuerzo son monitorizados en tiempo real. De este modo, nosotros como jefes podemos alentar o castigar a esos trabajadores que no tienen los valores esperados. Se puede definir un máximo y mínimo para que el sistema genere una alarma en tiempo real. Todos los valores son almacenados por un servidor y pueden servir para una recompensa en retribución variable o ascensos. Igualmente, si los datos no son buenos, si por ejemplo no ha ocurrido ninguna presión de nalgas en un mes, con estos datos se dispone de una herramienta objetiva para un despido.

Naturalmente usando este sistema hay que evitar cualquier cambio que suponga una reducción en el esfuerzo. Iría en contra de nuestra política de recompensar el esfuerzo. Las metodologías ágiles son totalmente contraproducentes ya que se ha demostrado que su uso continuado puede bajar el nivel de esfuerzo global. Hay que evitarlas a toda costa.

</ironic>

Í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.

Los tres primeros pasos en la gestión Ágil/Lean

Cuando uno empieza a querer organizar su forma de trabajar quizá lo que aporta Internet es demasiada información. Hace falta saber qué buscar para conseguir lo que necesitas para empezar a cambiar. Después de todos los años que llevo estudiando y aplicando las metodologías ágiles lo que aconsejo siempre es empezar con 3 sencillas cosas. El ABC de la gestión Agil.

1.- Daily Standup. Reuniones de máximo 15 minutos con los miembros del equipo en posición de pie en la cual cada uno comparte en qué trabajo el día anterior, en qué va a trabajar y qué obstáculos o problemas tiene en su camino.

Consejos:

  • No debe ser un informe al jefe. La información es de todos para todos
  • Debe empezar lo antes posible para que de pistoletazo al día pero que este presente el máximo número de personas
  • Si se abre un tema que necesite discusión larga se deja para después del daily.
  • Gente fuera del equipo puede hacer participaciones cortas que ayuden a algún problema. Lo fundamental es no pasarse de los 15 minutos.

2.- Tablero kanban. Panel en el cual hay una columna por fase por la que pasa cada elemento de trabajo representadas por etiquetas. Estos elementos pueden ser historias de usuario, diseños que hay que hacer, máquinas que montar, arreglar, etc.. Cada mes se limpian las etiquetas completadas en la última fase. Cada miembro del equipo mueve la etiqueta de una columna a otra según se va completando. Permite una visión común de cómo va el trabajo y permite tomar decisiones de mejora y de eliminar los bloqueos.

Consejos

  • Ponerlo en un lugar visible y accesible para todos
  • No debe haber más de 20 etiquetas por equipo para que se pueda ver de modo más sencillo
  • Debería haber límites máximo por columna aunque sean altos a principio. Si llega un momento en el que se supera ese límite debería analizarse la causa del problema y mejorar.
  • Ir bajando ese límite máximo según se va mejorando para conseguir un sistema más lineal y eficiente.

3.- Retrospectivas. Reunión a final de mes en cual se junta el equipo para ver qué han hecho bien y qué pueden mejorar. Se puede usar el método del barco  para además identificar las minas, es decir, los elementos externos que os afectan como equipo y para las que tenéis que estar preparados. No debería durar más de una hora u hora y media.

Consejos:

  • Sinceridad pero sin buscar culpables. Algo mal hecho es porque no se tenía conocimientos o herramientas para hacerlo mejor. Esta reunión sirve para buscar estas cosas.
  • Los problemas encontrados deberían buscarse soluciones. Asignar responsables para trabajar en ellas.
  • Se puede usar para dar pequeñas formaciones que ayuden al equipo. Club de lectura, vídeos de Internet, etc..

Con estas tres herramientas cualquier equipo puede empezar a trabajar mejor y de forma más organizada. Es posible que se vean nuevos problemas y se piense que antes no estaban, pero seguramente sea porque antes no se veían. Surgirán problemas que estaban ocultos y que ahora salen a la luz. Permitirá que surjan nuevas necesidades para ir mejorando cada vez más vuestro método de trabajo. Es posible que necesitéis nuevas herramientas para cubrir esas necesidades pero estas tres herramientas básicas os acompañarán día tras día.

Conseguir el ISO y el CMMI3 sin dejar de ser Ágiles, interesante reto

Este año en VSN nos hemos propuesto a pasar la certificación ISO para poder optar a proyectos en que lo requieren. Estamos con la ayuda de un consultor que nos va diciendo lo que tenemos que hacer.

De momento lo que vamos haciendo consiste en documentar todos nuestros procesos internos. No parece más que dejar bien por escrito todo lo que hacemos de manera corporativa. En desarrollo es concreto me toca escribir cómo manejamos los requerimientos en sprints, cómo hacemos seguimiento mediante los dailys y el Diagrama de Flujo Acumulado, como aseguramos la calidad mediante los tests automáticos y manuales. Como hemos ido escribiendo todo lo que ibamos estandarizando en las retrospetivas tenemos bastante escrito.  Sobre todo parece que hay que tener manual de todo lo que se desarrolle. No puede salir un desarrollo nuevo sin un escrito en el que se dice qué y cómo funciona. Yo espero que lo que escribimos como procedimiento de test para que otro desarrollador lo pruebe sea suficiente documentación.

Aparte del ISO se nos recomienda tener una certificación concreta de software. Yo estoy seguro que podemos optar a un CMMI 3 también con el modo ágil en el que trabajamos. De momento me toca ir empollando bien qué piden y si nos falta algo más que gestionar. Cuento con que mejoremos sin dejar de ser ágiles. Veremos si en lo que escribí a mediados de 2009 tenía razón.

Iré contando los avances…

¿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.

 

 

 

Negocios sin mentiras

En el libro “La Máquina de la Verdad” de Jams L. Halperin (conseguir) habla de una máquina de la verdad 100% fiable. Empieza usándose en ámbitos como juicios, en el gobierno y acaba siendo una tecnología que todo el mundo lleva encima como si fuera un reloj. Este detector de mentiras portable consigue erradicar la mentira de todos los ámbitos incluso en los negocios. Las empresas cuando hacen negocios entre ellas sólo se dicen qué necesitan de forma sincera y llegan a la mejor solución para ambos.

¿Qué ocurriría en el mundo de los negocios sin la mentira? ¿Que ocurriría si siempre dos partes que hablen entre sí buscasen la mejor manera de ayudarse y no de sacar el máximo provecho sin pensar en el otro?

La confianza es muy importante si se quiere conseguir la mayor eficiencia. En el manifiesto ágil se le dá una gran importancia. El 50% del manifiesto de hecho habla sobre ella.

Individuos e interacciones sobre procesos (Confianza en la gente con la que se trabaja)
Colaboración con el cliente sobre negociación contractual (Confianza cliente – proveedor)

Cuanta menos confianza, más trabajo extra se hace en contratos, controles, seguimientos,… que no dan valor directo al cliente y que son realmente un lastre para el equipo de desarrollo y la empresa en general. Ten más confianza con la gente con la que  trabajas y consigue que tengan más confianza en ti. Esto sí que será un WIN-WIN.

En Toyota la confianza se consigue con relaciones a largo plazo y colaboración mutua. Con los proveedores se colabora para que consigan entregar en menor plazo posible y con menor coste. No se rompe relaciones simplemente porque otro proveedor ofrezca un precio más bajo sino que la ayuda a que llegue a ese precio siendo más eficiente. La confianza del equipo se consigue también con una relación a largo plazo. Todos los trabajadores de Toyota son casi de por vida. El sueldo va aumentando año tras año de trabajo con ellos y los puestos avanzados se consiguen también después de haber trabajado mucho con ellos. De este modo se consigue que cada trabajador entienda la cultura de la empresa y sea una parte inseparable. Cada trabajador de linea tiene el poder de parar la cadena de producción en cuando ve un problema de calidad que no es capaz de arreglar hasta que pasa a la siguiente fase. Esto sólo se puede hacer cuando se tiene mucha confianza en todas y cada una de los personas con las que se trabaja.

Pregunta a tus clientes qué es lo que realmente quieren, no dejes que un contrato os ate  tanto a ti como a ellos. Satisface sus necesidades y, no solo conseguirás recompensa económica por el servicio, también conseguirás que vuelva a hacer negocios contigo. Ataros con un contrato blindado y, ni el cliente podrá ajustar su pedido a sus necesidades ni tu podrás salirte ni una coma aunque ello pueda dar más valor.