No estimes, rompe el trabajo pendiente

Estimar el trabajo pendiente es algo que se considera necesario para poder planificar el tiempo y los recursos de cara al futuro. Si trabajas con Scrum seguramente al principio del Sprint planificarás con tu equipo los puntos de historia que vais a meter en el sprint y también quizá las horas de las tareas. Gracias a esta planificación podemos tener «mas o menos» un sprint con una cantidad de trabajo controlada y una posible planificación de más a largo plazo en un release plan.

Si embargo, el trabajo de estimación realmente no es un trabajo que aporte valor al producto final. El que estimes con una precisión del 100% o del 20% no hará que el cliente obtenga más o menos valor y seguro que no pagará más por ello. Según la propuesta Lean debemos intentar reducir o eliminar aquellas tareas que no aporten valor al cliente y esta tiene pinta de ello. Entonces… ¿intentamos trabajar sin planificación del sprint o del producto sólo por esto?

Por otro lado, siempre se recomienda trabajar con historias lo más pequeñas posibles. La teoría de colas indica que con un tamaño de paquete de trabajo menor conseguimos una velocidad más constante que con tamaños muy dispersos. Además, desarrollando historias pequeñas, acortamos el tiempo de feedback y esto conlleva una reducción de errores. Muy bonito pero … ¿Cómo nos puede ayudar el tener historias pequeñas con el problema de la planificación?

Cuando tenemos historias más pequeñas conseguimos una homogeneización de los tamaños de las mismas. Esto es, hay poca diferencia entre la historia más grande y más pequeña que metemos dentro del sprint. Con un tamaño más o menos constante y una capacidad de desarrollo fija obtenemos una capacidad basada en historias por sprint. Según trabajamos así, Sprint tras sprint vemos que obtenemos un número más o menos constante de historias.  La misma precisión es la misma que se obtiene cuando estimamos por puntos. Esta cantidad fija de historias nos permite planificar el sprint y, si además rompemos mediante análisis las historias que componen el producto más allá del sprint, planificaremos los tiempos de entrega de producto.

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.

Cuando el desarrollador se pregunta «¿Qué voy a hacer hoy?»

Esta pregunta se pueden hacer muchos desarrolladores todos los días cuando entran al trabajo. Hay mucho trabajo por completar pero.. ¿qué es lo más eficiente que se puede hacer?

Cuando se intenta tener un sistema Agile/Lean es muy importante que el flujo de trabajo sea llevado mediante sistema PULL. Para conseguir esto las tareas deben atraerse hacia las ultimas fases del desarrollo. También hay que intentar reducir la cantidad de Trabajo en Curso (Work In Progress,WIP) por lo que antes de empezar nuevas características hay que intentar completar antes las que estan en curso.

Para conseguir todo esto, y con el apoyo de un tablero kanban fisico o virtual, los desarrolladores pueden decidir qué hacer en base a estas preguntas.

1.- ¿TENGO ALGUN TEST FALLIDO QUE DEBO ARREGLAR?  –> ARREGLARLO

Muchas veces los tests fallidos se acumulan y sólo se arreglan al final de sprint. Esto provoca que haya una acumulación de desarrollos y tests que pueden hacer que el deadline o fin de sprint se retrase. Debería ser la prioridad principal el completar los desarrollos ya hechos arreglando esos fallos que se han encontrado antes de otra cosa.

2.- ¿EL NUMERO DE TESTS PENDIENTES HA ALCANZADO SU MAXIMO? –> PASAR UN TEST

En VSN, el equipo de desarrollo ha definido cómo número máximo de historias esperando el test a 3. Si en el daily stand-up se ve que ha alcanzado ese número, se reparten 2 tests entre los desarrolladores para aliviar esa saturación. Naturalmente, ningún desarrollador testea lo que él mismo ha desarrollado, sino lo que ha hecho otro.

3.- ¿TENGO ALGUN DESARROLLO EN CURSO? –> CONTINUAR CON EL DESARROLLO

Naturalmente, una buenísima manera de avanzar es seguir con la historia y las tareas que había en curso.

4.- ¿PUEDO AYUDAR A TERMINAR ALGUNA HISTORIA EN CURSO? –> AYUDAR CON ESA HISTORIA

Si hay desarrolladores a los que se puede ayudar hay que hacerlo llegado este punto. Puede ser mediante el pair-programming, puede ser haciendo alguna tarea que se puede paralelizar, puede ser invesigando algo en Internet que necesite. Lo que se pueda hacer para ayudar a terminar antes con las historias que ya están en desarrollo.

5.- EMPEZAR HISTORIA LISTA EN ORDEN DE PRIORIDAD

Si a las anteriores preguntas se ha respondido NO pues no hay mayor problema. Se elige una historia por empezar siguiendo el orden de prioridad  establecido y a desarrollarla

Feature Toggle. La opción más ventajosa para conseguir la Entrega Continua

En el Manifiesto Agil el primer principio dice así:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software

«Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software útil»

Uno de los enfoques más importantes es poder dar al cliente software funcionando para que lo pruebe y nos aporte el feedback que permite hacer la aplicación cada vez más valioso para el cliente. Además, en la parte técnica, hacer entregas más frecuentes reduce el riesgo de cada una de ellas.

Captura de pantalla 2012-05-02 a las 23.03.41En el desarrollo tradicional. Las tareas de desarrollo y test se van acortando según se acerca el deadline. Durante todo el tiempo no se puede hacer release porque siempre hay desarrollos sin completar por uno u otro desarrollador. Cuando todo el testing ha terminado y todos los bugs y desarrollos se han cerrado es el momento de hacer el release de la aplicación.

Usando Scrum esto mejora algo:

Captura de pantalla 2012-05-02 a las 23.09.48

Reduciendo el tiempo de entrega y haciendolo más frecuente podemos ajustarnos más a los deadlines pactados con los clientes. Durante el sprint el código se considera no releaseable ya que solamente cuando se termina éste, todos los desarrollos se han cerrados y estan libres de bugs conocidos.

Aunque Scrum es un gran avance respecto al desarrollo tradicional, se puede ir más alla y poder ofrecer actualizaciones de manera continua y temprana. Hay varias formas de conseguir esto:

Forma 1: Desarrollar historia por historia

Todos los desarrolladores trabajan en la misma historia y se hace release cuando se termina. Esta es la manera más dura de conseguirlo. Hace falta gran madurez en el equipo pero también reduce el tiempo de desarrollo de cada historia. Durante el tiempo de desarrollo el código se considera sucio ( no releaseable) pero estos intervalos son cortos.

Captura de pantalla 2012-05-02 a las 23.22.10

Pero claro, quizá tu eres uno de los que dice. No todo se puede paralelizar, 9 embarazadas no dan a luz un niño cada mes.

Captura de pantalla 2012-05-02 a las 23.24.29

Sin embargo, en cuestión de desarrollo se puede paralelizar mucho las historias. Hay back-office y fron-end. Hay clases de store, de vista, de controlador, hay que desarrollar los tests, hay que preparar los scripts de bases de datos. Todos estos son tareas que algunas se pueden realizar en paralelo por varios desarrolladores. Necesita organización y planificación previa del equipo y coordinación durante el desarrollo. Así es como lo veo yo:

Captura de pantalla 2012-05-02 a las 23.27.56

Forma 2: Feature branching.

El auge de los nuevos sistemas distribuidos de control de código (DVCS) como Git, Mercurial o Plastic SCM tambien tienen características que permiten hacer branches a menudo. Esto es usado para hacer un branch por historia a desarrollar o feature branching. Una vez completada esa historia se incorpora a las ramas principales que sea necesaria para hacer el deploy.

Captura de pantalla 2012-05-02 a las 23.31.48Esto es un ejemplo de branches usando un sistema de feature branches y varias ramas de integración. Hay partidarios de los features branches pero yo me inclino más por la opinión de estos dos conocidos personajes.

Captura de pantalla 2012-05-02 a las 23.35.33Martin Fowler y Jezz Humble afirman que el uso de feature branches va en contra de la Integración Continua, necesaria para tener feedback de integración temprano y realizar los merges con las ramas principales menos dolorosos. Además es necesario una gran bateria de tests automaticos para evitar bugs ya que es necesario testear la funcionalidad varias veces. Primero en la rama en la que se desarrolló, después en cada una de las ramas en la que se integra. Si es necesario el tests manual esto puede ser muy doloroso. Sólo recomiendan el Feature Branching en equipos muy muy maduros.

Forma 3: Feature Toggle.

Esto se basa en poder desarrollar las funcionalidades, teniendolas integradas junto con el resto del código pero que no afecte al producto si se tiene que hacer release a mitad de desarrollo. El truco está en desactivar el link o el acceso a la nueva funcionalidad hasta que esté completamente desarrollado y testeado.

Captura de pantalla 2012-05-02 a las 23.41.48

Esta tercera forma, aparte de permitir hacer release a cada momento teniendo el código integrado también tiene una serie de ventajas extra.

Ventaja 1. Canary Releasing.

Este concepto proviene del sistema utilizado en las minas para detectar fugas de gases. Ponían jaulas con canarios a lo largo de los tuneles y estos, al ser más delicados que las personas, morían rapidamente en caso de fuga de gas letal. Efectivamente es una tecnica un poco triste por perjudicar a los canarios pero hay que contrastarlo con las vidas humanas que salvavan.

Moviendonos al terreno del software (donde hay menos gases involucrados), el Canary releasing significa poder ir activando funcionalidades por zonas. Primero las activaríamos en sistemas internos, después en sistemas de clientes con confianza y si todo funciona correcto al final se activaría en clientes críticos. Si en alguna de estas zonas da problemas, dejaríamos de avanzar antes de resolver el problemaCaptura de pantalla 2012-05-02 a las 23.46.38

Ventaja extra 2. Marcha atrás rápida.

Alguna vez habeis programado una actualización a un cliente, se le ha dicho que con esta nueva versión va a tener los bugs encontrados arreglados y además la nueva funcionalidad. Ejecutas el instalador, actualizas el sistema y la nueva funcionalidad no va ni para atrás y los usuarios se empiezan a quejar. La opción normal es 1.- Gritar, 2.- Desinstalar la última versión instalada,3,. Deshacer manualmente los cambios que hubiera hecho el instalador que no hace al desinstalar,.4.- Instalar la versión anterior. 5,. Volver a gritar.

Captura de pantalla 2012-05-02 a las 23.50.16

Mediante el Feature Toggle nos permitiría poder simplemente desactivar la nueva funcionalidad sin tener que desinstalar. En cuanto la tuvieramos arreglada y el sistema actualizado, solamente se vuelve a activar. Bastante menos doloroso.

Ventaja extra 3: Customización del producto.

A todos nos ha llegado las estadisticas de que los usuarios sólo utilizan una pequeña parte de la funcionalidad. Con el resto ocurre dos cosas: 1. Les molesta que esté o 2,. Nos molesta que lo toquen. La opción más sencilla es desactivar la funcionalidad que no van a necesitar haciendole el interfaz más sencillo y evitando posibles problemas.

Captura de pantalla 2012-05-02 a las 23.54.38

Implementación propuesta.

En VSN vamos a tener una tabla por producto. En esta tabla habrá una entrada por característica candidata a ser activable o desactivable por el feature toggle.

Captura de pantalla 2012-05-03 a las 00.00.10

En entorno de desarrollo y test se le pondrá a todas las filas la columna ACTIVE a true así aparecerá todo para probar. Sin embargo, en el SQL de release sólo estarán activas las funcionalidades completadas y que formen parte del producto por defecto. De este modo aprovechamos todas las ventajas de este sistema. Le hemos añadido una columna leible por humanos porque todo esto seguramente acabe en un panel de activación y desactivación para un futuro «Gate Keeper» guardian de las características.

Actualización 7/6/2012: Nosotros instalamos de momento sólo sistemas llave en mano. Es decir, instalamos en cada cliente una máquina con el server. En cada server hay una base de datos y en esa base de datos se puede activar o desactivar sus features. Así sí que se permite activar y desactivar por Canary Release. Si el sistema está en la nube falta añadir a la tabla una columna referente a el area del cliente (definida por tí) , region geografica y sacar su region por geoip,.. o algún otro tipo de agrupar los clientes.

La parte impredecible de una estimación

¿Cuanto vas a tardar en terminar esta tarea? Esta pregunta puede resultar muy fácil de responder y hacer una respuesta con una precisión absoluta, o tambien puede resultar muy dificil y dar una respuesta que nada tenga que ver con lo que al final se termina tardando.

¿De qué depende?

En tareas como las que solemos hacer los desarrolladores de software, el resultado de nuestro trabajo no es solamente el código generado sino tambien se genera conocimiento para el propio desarrollador. Para identificar qué parte del tiempo se ha utilizado para generar la funcionalidad y qué parte del tiempo se ha utilizado para generar el conocimiento sólo hay que hacerse una pregunta:

¿Qué tardarías ahora si tuvieras que repetir la misma tarea?

Ese tiempo que responderías corresponde con el tiempo usado en la generación del producto y el resto fue el usado en la generación de conocimiento.

KnowledgeGeneration

En entornos en los que el lenguaje de programación es muy conocido y el tipo de producto final se ha hecho muchas veces, hay poca generación de conocimiento y el tiempo que se tarda se puede predecir facilmente.

LowLearning

Sin embargo en entornos de innovación continua muchas veces el tiempo de generación de conocimiento es la mayor parte.

HighLearning

Realizando pair-programming se reduce el tiempo impredecible ya que la en la tarea sólo se genera el conocimiento que no tiene ninguno de los dos componentes de la pareja.

PairProgramming

Este tiempo de duración desconocida puede llevar al traste cualquier deadline. En proyectos tradicionales waterfall puede provocar que no se llegue a tiempo y en proyectos Scrum provocan que los sprints se solapen, estando varios días del siguiente sprint terminando tareas retrasadas. Una manera de minimizar su impacto es reducir la cantidad de  trabajo en curso, reduciendo el tamaño de las historias y focalizando a todo el equipo en la consecución de la misma en lugar de tener muchas historias abiertas.

Scrumban, de moda pero quizá no necesario

Nota: El Scrumban del que hablo no tiene nada que ver con el que acuña David J Anderson

Hace poco escribí un tweet en el que decía que el Scrumban no era necesario. Los 140 caracteres del tweeter no dan espacio para una explicación de esto pero voy a intentarlo aquí.

Scrumban, al menos el que conozco yo, se basa en dos paneles. Un panel con las historias de usuario del sprint, características y bugs a desarrollar provenientes del product owner, y un panel kanban con el resto de tareas que no tienen que ver con las historias de usuario previstas. Normalmente son problemas a resolver de soporte de algún cliente o relativas a otros departamentos de la empresa.

En el panel kanban se establecen 3 prioridades relativas a las tareas del panel Scrum.

  • Una prioridad llamada ASAP, en lo que se hacen tareas cuando el trabajo pendiente en el panel Scrum sea menor del ideal que tocaría para ese día.
  • Una prioridad llamada PRIO en se cogen tareas cuando se ha terminado en las que se está trabajando en ese momento.
  • También una prioridad FIRE en la que cuando se añade una tarea hay que hacerla de modo inminente dejando el trabajo a mitad. Naturalmente en la retrospectiva se analiza por qué ha ocurrido una tarea FIRE y se intenta evitar que ocurra en el futuro.

Yo veo un problema grave en el hecho que sean dos paneles con la misma función y añade gestión extra que quizá no sea necesaria. Además tener dos sitios donde mirar el trabajo es más complejo que tener uno solo en el que esté todo el trabajo que se está realizando.

Cuenta con que el Product Owner es el que pone las tareas al kanban y requiere que las prioridades sean muy claras. Tambien es una herramienta para que el equipo justifique ante el PO el haber hecho más o menos puntos de producto.  Yo nunca he entendido esta necesidad de justificación ya que todos deberíamos tener los mismos objetivos, que es dar valor a los clientes.

Yo entiendo tres prioridades que encajan en un solo panel.

  • La prioridad FIRE es que no hace falta ponerla en ningún panel, se le dice a la persona o personas involucradas que se ponen a ello inmediatamente.
  • La prioridad «lo tendrá a final de este sprint» en el que es posible que salga alguna historia que ya estuviera en el  sprint para que quepa la nueva.
  • La prioridad, «lo estudiaremos para el siguiente sprint» en el que se encajará como una historia más para el siguiente sprint dejando inalterable el actual.

Lean y Agile, dos puertas para el mismo camino

Hay muchos debates sobre diferencias entres Agile y Lean. Yo personalmente pienso que los dos tienen los mismos principios, lo único que Agile está hecho por desarrolladores para desarrolladores mientras que Lean está hecho en el ámbito de la producción y tiene un ámbito más amplio. Voy a repasar las entradas del manifiesto y veremos como van por los mismo caminos.

Individuos e interacciones sobre procesos y herramientas

Nadie mejor sabe cómo se hace mejor un trabajo que el propio trabajador. Todos los procesos que se incorporan deben ser consensuados y propuestos por las personas que tienen un trato directo con el producto.  Los cambios de herramientas deben ser estudiados concienzudamente y deben tener como único fin ayudar a la persona.

Software funcionando sobre documentación extensiva

Lean intenta eliminar cualquier tipo de desperdicio (waste) que no aporte valor al cliente. La documentación ha sido historicamente el mayor tipo de trabajo del desarrollador realiza que no aporta valor al cliente por lo que reducirlo en medida de lo posible es una manera de centrarle en lo que verdaderamente le aporta valor.

Colaboración con el cliente sobre negociación contractual

La máxima flexibilidad y poner al cliente en el centro es crucial para Lean. Además cuanta más información se tenga de él en el momento que justo sea necesario para aportarle lo que realmente necesita más valor se le dará.

Respuesta al cambio sobre seguir un plan

La observación y la respuesta rápida a los problemas es también uno de los principios importantes en Lean. Para responder rápido a los cambios, se debe ver a mayor información posible y que esté disponible para todo el mundo. También hay que responder rápido a los cambios poniendo máxima prioridad en darles respuesta.

Retrospectivas de ámbito global

Las retrospectivas  son un punto muy importante en el mundo ágil.  Es el momento de reunirse el equipo y ver cómo mejorar y adaptarse al entorno cambiante. Cada sprint es distinto del otro y tanto las necesidades del mercado, del producto, de la tecnologia y otros muchos factores cambian muy rapidamente.

En la retrospectiva hay que exponer los problemas y resolverlos por ejemplo mediante la técnica de los 5  por qués  (5 whys) o con la de la raspa de pez (fishbone). Las soluciones propuestas para resolver los problemas se añaden a la lista de tareas como tareas de proceso que se resolverán junto a las tareas de producto en el siguiente sprint. De este modo el equipo va mejorando a sí mismo sprint tras sprint siendo cada vez más productivo y más feliz.

Hasta aquí todo lo que se puede hablar (muy, muy resumido) de una retrospectiva cuando hablamos de Agile o Scrum. Pero ¿realmente ese es el objetivo final? ¿Sirve de algo tener un equipo de desarrollo que va a cientos y cientos de puntos por sprint mientras que el resto de los departamentos van como con bolas de preso atadas a sus pies? ¿Es suficiente que los desarrolladores  entren y salgan  con una sonrisa en la boca diariamente mientras que en el resto de los departamentos  sufre los mismos problemas semana tras semana? ¿Qué pasa con el departamento comercial, el de operaciones, el de soporte, el de marketing…. ? ¿No estamos todos en el mismo barco?

La perspectiva Lean dice que hay que ir mejorando el flujo de valor (desde el comercial hasta la postventa) y no sólo centrarse en una fase (desarrollo).

Cuando estuve en la Conferencia Agile Spain 2011, Xavier Quesada habló del Failure Demand. Esto es cualquier trabajo realizado a causa de algo que se ha hecho mal anteriormente. Puede ser la corrección de bug, el volver a generar una base de datos porque alguien la ha borrado accidentalmente,… Propuso algo que llevé a la practica que es poner un tablón con el titulo ¿En qué he desperdiciado el tiempo? Ahí la gente pone etiquetas como por ejemplo «4 horas ayudando a soporte a instalar el sistema». En la retrospectiva se analizan todas esas etiquetas y se buscan soluciones para que no vuelvan a ocurrir.

Esta es una idea que se puede aplicar globalmente. Cada departamento tiene su propio tablón con sus Failure Demands. Cada 2 o 3 semanas se juntan los miembros del departamento y los analizan exactamente igual que hace el departamento de desarrollo. Hay problemas que pueden solucionar por ellos mismos pero hay también problemas en los que parace que tienen que  intervenir otros departamentos para solucionarlo.

Una vez al més los directores de departamento se reunen y evaluan estos problemas que no han podido ser resueltos localmente. Entonces hablan entre ellos y deciden cómo solucionarlo de la manera más eficiente de manera global. Hay problemas que son resueltos por otros departamentos efectivamente pero tambien hay problemas que vuelven al departamento de origen, ya se ha decidido que lo más eficiente es que lo resuelvan ellos mismos.

Eduard Estivill, Carlos González, Rosa Jové ¿Qué hago con mis niños a la hora de dormir?

Para todo padre novel siempre llega el momento en el que te planteas si dejar a tu nenito o nenita que duerma en su propia habitación o si dejar que siga durmiendo en vuestra cama. Como para opiniones, colores, cada persona con la que hables seguro que está siguiendo el consejo de algun libro, pedriatra, médico. Normalmente los consejos vienen de uno de estos tres autores.

Voy a intentar ser lo más imparcial que pueda y dar pequeñas pinceladas de cada uno de los autores. He sacado la información de las propias entrevistas y páginas personales de los autores. Si hay algún dato incierto o sesgado, hazmelo saber en algun comentario y lo investigaré.

Eduard Estivill

Médico especialista en alteraciones del sueño. Autor de numerosos libros entre ellos el que más repercusión ha causado: «Duermete Niño» en 2003. En él  explica un método para conseguir que el niño duerma por sí mismo en su propia cama.

En el libro se explica minuciosamente cómo lograr que el niño identifique la oscuridad de su habitación, y un peluche,  (por ejemplo) con la hora de irse a dormir. Después de cenar, Estivill recomienda pasar unos 10 minutos con el niño, antes de llevarle a la habitación. Una vez allí, es importante que los padres no se conviertan en «elementos externos asociados al sueño», para ello deben salir de la habitación antes de que el bebé se quede dormido: «No podéis ayudarle a conciliar el sueño meciéndole, acariciándole o haciéndole mimitos», señala el autor. Ésta es tal vez la fase más dura para los padres («los dos primeros días de tratamiento son duros», advierte Estivill). El método establece una tablas de tiempo para realizar pequeñas visitas al dormitorio para tranquilizar al niño si este llora. Durante estas visitas, en ningún caso los padres cogerán en brazos al niño, ni le mecerás, simplemente, hay que tranquilizar al niño, haciéndole saber con voz firme que no está sólo.

«Sin duda. Si el niño no aprende a dormir, entre los cinco y los 14 años sufrirá otro tipo de insomnios, se mostrarán inseguros a la hora de dormir no querrán pasar la noche en casa de amigos, seguirán acudiendo a la cama de los padres… Esto se debe a que estos niños arrastran un mal hábito porque nadie les ha enseñado a dormir»

El método está basado en el Método Ferber. En la wikipedia en inglés se puede tener un resumen del procedimiento.

  • Haz una preparación antes de llevar al niño a la cama. Esto incluye actividades rutinarias.
  • A la hora de dormir, deja al niño en su cama y abandona la habitación.
  • Vuelve a intervalos a la habitación a confortarlo (sin cogerlo/a). Por ejemplo, en la primera noche, se recomienda volver a los 3 minutos, despues a los 6, entonces 10 y así hasta que se duerme.
  • Cada noche, vuelve a intervalos cada vez más largos que la anterior. Por ejemplo, la segunda noche puedes empezar por 5 minutos, entonces 10, 12 y así hasta que se duerme

Carlos Gonzalez

Pediatra y fundador de la asociación Catalana Pro-Lactancia Materna. Especialista en lactancia materna por la Universidad de Londres. Uno de los máximos exponentes en metodos no conductistas, conocidas como crianza de apego. Uno de los libros de mayor acogida fue «Bésame mucho, cómo criar a tus hijos con amor«, el mismo año que el libro de Estivill  (2003)

Citas obtenidas de entrevistas:

«Es muy importante que aprendan desde pequeñitos a dormir acompañados, porque así es como solemos dormir los adultos. Imagínate que no aprende a dormir con otras personas, y que cuando sea mayor no se quiere acostar con su marido. ¡Sería terrible! ¡No la conseguirías casar!»

«pienso que aquellos niños que desde el nacimiento han dormido solos se sienten más inseguros, y que su evolución es precisamente la contraria.»

«Los pediatras no son más que un reflejo de la sociedad. Sus malos consejos son similares a los malos consejos de familiares y amigos, y reflejan en gran parte su propia experiencia personal con sus propios hijos. Ahora hay doctoras que dan el pecho dos años y duermen con sus hijos, evidentemente sus consejos serán muy diferentes

Pregunta: «Mi bebé prácticamente tiene que estar conmigo prácticamente todo el rato, o para tomar teta, para dormir..»

Respuesta: «Los bebés necesitan atención constante, 24 horas. Es lo normal. Por eso la mayor parte de las madres del mundo llevan a sus bebés colgados a la espalda»

Pregunta: «Buenos días. Tengo un hijo de casi 3 años que necesita para dormir que esté a su lado y cuando se queda dormido ya lo puedo dejar solo, hasta ahora no tenía problema ninguno pero me preocupa el que ahora estoy embarazada de nuevo y cuando llegue el bebé mi hijo debería saber dormir solo..

Respuesta: «Bueno, si está usted sola, cabrán los tres en la cama sin problemas. Lo importante es que la madre esté en medio, porque uno de tres años podría golpear sin querer al recién nacido….»

Pregunta: «.. lactación materna exclusiva hasta los 6 meses, ya que en el caso de mis dos hijos, me han aconsejado introducir los cereales sin gluten a los 4 y la fruta a los 5 meses..

Respuesta: «Bueno, algunos pediatras todavía están dando recomendaciones antiguas.
Es comprensible. La alimentación no es una cuestión médica. El pediatra no es ni cocinero ni ama de casa. Procura estar al día de las novedades en el diagnóstico y tratamiento de las enfermedades, que es su profesión.»

Rosa Jové,

Licenciada en Psicología por la Universidad Autónoma de Barcelona, está especializada en psicología clínica infantil y juvenil y en psicopediatría (bebés de 0 a 3 años). Igualmente es licenciada en Historia y Geografía con especialización en antropología de la crianza. Autora del libro «Dormir sin lágrimas» publicado en 2007.

«No hay diferencia de éxito entre los métodos que enseñan a dormir a base de dejar llorar mediante una tabla y los que simplemente dejan llorar. Si la hay entre aplicarlo antes de los 18 meses o después», escribe esta especialista en el sueño. Para Jové, los métodos de adiestramiento no enseñan a dormir, «solamente provocan un shock emocional que altera los niveles de las principales hormonas que regulan nuestras emociones, y además le demuestran que no vale la pena quejarse porque nadie les responderá. Por eso funciona mejor en niños pequeños, ya que son los que tienen más posibilidad de shock».

«Todos los métodos de adiestramiento para dormir niños basados en dejarles llorar según una tabla me parecen crueles. Aaunque no llegaran a dejar ninguna secuela psicológica en el niño, pienso que estamos en una sociedad en la que el fin nunca justifica los medios y en ese sentido, dejar llorar a un niño, aunque sea para dormir, no me parece bien»

«Si un niño de seis años todavía necesita compañía de sus padres para dormir es porque le cuesta estar relajado para iniciar el sueño y necesita una figura conocida para tranquilizarse. Pueden hacer dos cosas, una de ellas dejarlo tal cual porque evidentemente el niño un día u otro se va a quedar dormido solo, pero si quieren adelantar ese momento, lo que pueden hacer es intentar relajar al niño antes de ir a dormir»

«Si el niño no ha dormido habitualmente en la cuna, evidentemente ese cambio hay que hacerlo gradualmente porque si no el niño podría no aceptarlo bien en los primeros días. Sobre lo de que se duerma en brazos, no es ni un buen hábito ni un mal hábito, simplememnte si el niños se acostumbra, el niño lo va a dejar cuando sea mayor otra cosa es que antes de ese momento los padres lo quieran dejar antes, porque pesa, y entonces ellos mismos tendrán que ir deshabituándole

En una entrada de blog que escribe la propia autora habla de 4 estudios (Spitz, Harlow, Bolwby, Mckenna) como pruebas de que lo que se hace en el metodo Estivil puede causar secuelas. Me he molestado en buscar cada uno de estos cuatro estudios.

Rene Spitz:  (1887-1974).

Psicoanalista americano nacido en Hungría. Spitz desarrolló el termino depresión anaclitica por separación emocional parcial  (la perdida de una persona amada). Cuando la persona perdida vuelve al niño en un periodo de 3 a cinco meses, se recupera el niño en su estado normal. Si se aparta más de cinco meses, empiezan a mostar los sintomas de deterorizacion seria. Spitz llamó a esto deprivacion total. En este enlace hay un vídeo que pone los pelos de punta sobre niños apartados de su madre durante largos periodos. No apto para corazones sensibles. Aparetemente este estudio no tiene relación con el método Estivill.

Harry Harlow: (1905-1981).

Psicologo americano conocido sobre todo por sus experimentos de separación maternal y aislacion social en monos. Estos experimentos demostraton la importancia del afecto y la compañia para el desarrollo social y cognitivo. Los experimentos del Harlow fueron controvertidos. Incluian meter a pequeños macacos en camaras de aislamiento hasta 24 meses. Estos salieron de las cámaras severamente afectados. Es un estudio similar al de Spitz pero en simios. Menor relación si cabe con el método Estivill.

John Bowlby(1907-1990).

Psicoanalista. En 1951 expuso que la maternidad es inutil si se retrasa hasta despues de 2 años y medios o 3. Para la mayoria de los niños, si se retrasa hasta despues de los 12 meses, existe un periodo critico. Si la figura de apego se rompe durante el perido critico de los dos años el niño sufrirá daños irreversibles consecuencia de esta separacion maternal. Un estudio tambien similar al de Spitz.


James McKenna

Como director del Laboratorio de  Notre Dame’s Mother-Baby Behavioral Sleep, es conocido por hacer los primeros estudios psicologicos y de comportamiento sobre las diferencias del dormir en solitario o con los padres. McKenna es un acerrimo defensor del colecho y centra su investigacion en la relacion entre situaciones al dormir, metodos de alimentacion y factores de riesgo del sindrome de muerte súbita . Puedes leer aquí el estudio (en inglés). Este estudio sí tiene relación con el tema del sueño y parece  muy interesante pero sigue sin relacionarse con los posibles problemas que apunta Rosa Jové sobre  dejar llorar al niño durante minutos hasta que se duerme. Si alguien ve esta relación, por favor que  me envíe la referencia y actualizo el comentario gustosamente.

Opinón personal (ahora sí)

En este aspecto cada uno es libre de tomar sus propias decisiones. Sobre todo hay que estar abierto a otras opiniones y no tomar como dogma ninguna de ellas. Habrá padres que prefieran vivir la paternidad lo máximo posible y por las noches  y  llevar a los niños a sus camas  y hay otros que prefieren  vivir la paternidad lo máximo posible y  tener  a sus hijos en sus camas.

Fuentes:

http://www.elmundo.es/encuentros/invitados/2006/06/2070/

http://comunidad.diarioinformacion.com/entrevista-chat/3196/Salud/Carlos-Gonzalez/entrevista.html

http://www.elmundo.es/elmundosalud/2003/01/28/pediatria/1043756488.html

Cosas que me llevo en la maleta del CAS2011

Acabo de escribir ya un post sobre unas reflexiones que he tenido despues de la conferencia. Como lo tengo todo muy vivo en mi memoria quiero escribir aqui lo que más me ha llamado la atención y lo que me ha resultado más util. Así lo tengo guardado yo y lo comparto por si a alguien más tambien le interesa.

Empezamos con la keynote de Xavier Quesada. Habla del agilismo como esperanza para salir de la crisis. Un giro hacia la calidad, calidad que no genere «Failure Demand» (trabajo generado por errores). Focalizarse en trabajo no productivo para eliminar sus causas. Voy a usar la ideal del tablón donde escribir en qué se ha desperdiciado el tiempo de los desarrolladores y evaluarlo en la retrospectiva.También habló del ultimo momento responsable, hay que retrasar la decisión lo más posible para tener la mayor información.

Después me fuí al Workshop Kaizen. Juan Felipe Pons, un experto en Lean para construcción, que está visitando a todos los expertos mundiales en el tema.  Explica como se puede modelar el flujo de valor, todas las ramas y ciclos de elementos que pasan de departamento en departamente o al cliente para optimizar ese flujo como un todo.

Sigo en el track verde y empieza la charla sobre equipos autoorganizados. Me ha resultado útil  ver que exisite un progreso medible y un trabajo para logar equipos autoorganizados. No es algo que salga de la noche a la mañana pero existen métodos para ello.

Nos vamos a comer paellas ágiles. Lo de ágil no sé si era por lo de hacerlo de pié. Esto quizá fue un error porque no se pudo disfrutar del plato de arroz al ser complicado comerlo sin sentarse.

La charla «7 ideas para mejorar tu equipo ágil» quizá para mi fue la más flojita. Resultó curioso el tema del teletrabajo y que hay que mimar al teletrabajador.

Después entró Enrique Comba con fondo de AC/DC. Hizo una entrada espectacular y la charla en sí para mí fue muy buena. Me sorprendió la aparición momentanea de Uncle Bob. Realmente hace falta un cambio de forma de pensar y hacer del cliente como parte del equipo en lugar de como el enemigo. Hace poco , cuando hablaba con un amigo me comentó lo mismo, hace falta centrarse en hacer ganar al cliente dinero para ganar uno mismo.

Después del café entró David Bonilla en acción. Me encanta su forma de ver el desarrollo (y que comparto). Hace mucho tiempo que sigo su blog y su tweet y puedo decir que en su charla también encantó al auditorio. He descubierto que soy un esclavo de las empresas que usan gamification como estrategia. Las puntuaciones, los rankings y las insignias hacen que compremos danones, viajemos en iberia, hagamos check-In de foursquare con mucho placer. Lo que veo dificil es poder elegir un baremo que sea justo para todos. Si se hace un ranking de builds rotos, el que más rompe no tiene por qué ser el peor desarrollador sino el que se come más marroles,  por ejemplo.

El viernes aparecí en la keynote de J.B. Rainsberger, usé toda mi capacidad de entender el inglés para no perdeme detalle de toda su experiencia.

En la charla de integracion continua vs controlada por Pablo Santos presentó el uso de branches por tarea como la manera más eficiente de trabajar en equipo. La ventaja que le veo principalmente es poder subir cambios a tu branch personal como forma de tener backup de tu codigo sin romper el build. No tengo claro que sea lo que necesitemos actualmente en mi oficina.

Después me fuí otra vez al trunk verde y escuché atentamente la charla de Vanesa Tejada sobre visual scrum. Muy útil el poder usar un sistema visual tambien para uso personal de Product Owner e incluso para el propio CEO.

Por terminar, el tema que creo que más aplicación directa puedo hacer. Gracias a Jose Ramón Diaz sé como mejorar las retrospectivas. Como resumen 3 cosas: haz que todos hablen desde el principio para que les sea más facil después, obten la causa raiz de los problemas (5 why’s o fishbone) y añade como tareas el resolverlos para que no queden en el olvido.

El próximo año lo veo dificil ya que es en Extremadura pero de momento tengo suficiente food for though para unos meses como mínimo.

Buenísima organización, gente increible y contenido utilisimo.