Category Archives: Productividad

Potenciación de equipos (parte III)

Al fin llega la tercera parte de la charla de Potenciación de equipos. Vamos allá.

Para que un equipo esté equilibrado y dependa lo menos posible de personas externas a él que puedan convertirse en un obstaculo o un cuello de botella,  cada uno de estos roles deben identificarse para ejercitarlos y desarrollarlos entre todos los miembros del equipo.

  • Coordinador: Coordina los esfuerzos de todos para alcanzar metas, aunque no ocupe el cargo de líder. Hay que evitar que una misma persona mantenga este rol durante mucho tiempo y se recomienda que se vaya rotando entre todos los miembros del equipo.
  • Impulsor. Está lleno de energía, “empuja” a los demás para avanzar en el trabajo. Su optimismo y decisión para afrontar los retos hace ver al resto que cualquier cosa es posible.
  • Creador. La persona creadora está llena de ideas,es fuente de propuestas y sugerencias originales y sencillas. Es importante que esta persona entienda perfectamente el ámbito del problema para que saque su máximo potencial.
  • Evaluador. Analiza las ideas presentadas, valora sus pro y sus contra, proporciona instrumentos de análisis. En las reuniones se puede ver frecuentemente debates entre el creador y el evaluador que puede suelen acabar en soluciones muy buenas.
  • Realizador. Es el organizador práctico que transforma las decisiones y estrategias en tareas definidas y realizables, que los miembros del equipo puedan manejar. Es el que tiene más claras las tareas en las que se descompone una historia de usuario y su papel es fundamental para plasmarlas en el kanban.
  • Investigador. El que aporta ideas del “exterior” de la organización, su papel principal es evitar que el equipo se quede estancado. A veces se confunde con el “creador” pero, a diferencia de este, no aporta ideas originales, sino conocidas por sus lecturas, observaciones, u otras fuentes externas. Es el samurai del google, no hay ejemplo de código fuente  o solución a un problema que se le escape.
  • Comunicador. El más sensible para identificar necesidades e inquietudes de los demás miembros.. Su instinto lo lleva a crear ideas en los demás, sirve de “puente” en el manejo de conflictos. Ayuda a disolver las discusiones entre dos personas que no entienden sus posturas entre sí, explicando a cada uno el punto de vista del otro.
  • Detallista. Se preocupa por lo que puede estar mal hecho y por los detalles para asegurarse de que  nada se ha pasado por alto. Ayuda mucho en las revisiones finales de las historias de usuario porque siempre detecta el problema que a todo el mundo se le ha escapado.

El tema del lider en un equipo ágil siempre es tema de debate. ¿Tiene sentido un lider en un equipo autogestionado? Yo creo que siempre es útil una persona cuyo objetivo sea hacer lo posible para que el equipo sea productivo, esté unido y contento con su trabajo.

Esto requiere una serie de funciones:

  • No dice qué hacer, pregunta. Encuentra las preguntas adecuadas para provocar las ideas en el equipo.
  • Alienta la creatividad. No reprocha los fracasos ni las ideas extrañas. Lo contrario podría llevar a  que se los miembros de equipo autolimiten en sus ideas para prevenir “broncas”. Todas las ideas son analizadas y evaluadas sin descartarlas por adelantado
  • Alienta la participación. Todos los del equipo deben participar. El lider debe estar atentos a personas que no hablan, normalmente esta falta de palabras indica falta de entendimiento.
  • Propone mejoraas (coach). Investiga en metodologías y las propone al equipo. Intenta mejorar el número de puntos a realizar por sprint.
  • Les incluye en las decisiones que les afectan, por ejemplo, participan en la selección de personal que formará parte del equipo.
  • Evita impedimentos (papel del Scrum Master)
  • Se asegura que el equipo técnico este siempre en funcionamiento
  • Se come las reuniones innecesarias para el equipo, las que no les aporta visión de producto.
  • Hay una que no comenté en la reunion de Agile Alicante pero salió el tema en la cena posterior. El lider debe aislar al equipo de las tensiones que puede haber en el resto de la empresa. Debe hacer de escudo de toda la negatividad para que el clima en el equipo de desarrollo sea favorable a la creatividad y la calidad técnica.

Antes de terminar quisiera recomendar dos libros que me han encantado y que hablan de la psicología del equipo son dos:

Management Rewired (del que ya hablé en otro post)
Peopleware. No se puede llevar un equipo de desarrollo sin leerlo.

Anuncios

Potenciación de equipos (parte II)

Después de una semana mortal de trabajo vuelvo a estar en posesión de mi tiempo. Voy a continuar con la exposición que di en la sesión de Agile Alicante el 13 de Mayo. Puedes ver la primera parte aquí.

Cuando trabajamos con un equipo, ya sea de desarrollo de software o en otros entornos, no hay que olvidar que este equipo tiene una serie de necesidades. Prestar atención a cada una de ellas es importante como lider de équipo para desarrollarlo y sacar el mejor partido de él.

Si queremos que el equipo esté motivado, que sea capaz de juntar su esfuerzo con el de los compañeros para conseguir un objetivo común, no hay que olvidar que todos los miembros deben tener una visión global y clara de ese objetivo. El Product Owner es el responsable de que el equipo tenga una visión de alto nivel del producto a desarrollar. Con visión de alto nivel me refiero a que hay que evitar el dar visiones parciales sólo a los desarrolladores que van a realizar cada pequeña parte. Cuando el equipo conoce perfectamente qué tipo de software va a realizar, quién van a ser los usuarios, cual es la competencia,etc..  se produce la verdadera generación de ideas que hace de un producto algo innovador y de gran calidad.

Un error común que se suele cometer, es que los desarrolladores sólo conocen los problemas del software ya son los que tienen que resolverlos o ayudar a resolverlos. Sin embargo, elementos como el número de horas sin incidencias, el número de usuarios concurrentes que lo han usado sin causar saturación u otros elementos positivos, normalmente no llegan a oidos de los desarrolladores. Estos elementos positivos son un potente aglutinador que mantiene al equipo unido y motivado y con fuerzas para superar nuevos retos.

El entorno fisico en el que trabaja el equipo tiene mucho que ver con cómolos miembros se sienten parte de ese equipo . Los cubículos que aun parece que se usan en algunos entornos hay que descartarlos completamente. La ubicación de los puestos de trabajo debe fomentar una colaboración directa cara a cara. El equipo además debe disponer de una zona común para realizar el daily, juntarse para analizar los problemas, … Sin embargo no hay que olvidar que el trabajo tambien requiere concentración. El equipo debe disponer de elementos  para indicar que un miembro está en estado de concentración. Quienes conocen la técnica pomodoro sabrán que es importante que durante los 25 minutos de trabajo intenso no se reciba interrupciones. Hace poco descubrí el CherryTomato que marca en el skype con el estado “Do Not Disturb” durante el tiempo del pomodoro. Esto sirve para que el resto del equipo sepa facilmente si  es momento de hacerte las preguntas o si se las apunta para después.

El equipo además necesita de elementos de gestion visual. El kanban es un buen elemento para que se auto-gestionen el progreso de los proyectos y se asignen el trabajo a sí mismo. Les permite encontrar los cuellos de botellas y resolverlos ellos mismos.

El equipo debe ser multidisciplinar y multinivel. Esto no quiere decir que cada miembro del equipo debe ser multidisciplinar y dominarlo todo sino que las especialidades combinadas de los miembros forma la capacidad de equipo que los proyectos necesitan. Tampoco hay que ver a los miembros como clones entre sí sino cada uno puede tener distintas capacidades, personalidades y necesidades. Esto último normalmente se omite cuando se piensa en un equipo. Puede haber un miembro que necesite doble monitor mientras que otro necesite una impresora cerca. Aunque cada miembro trabaje primero en la parte que más conoce y controla, esto no quita que si ha acabado su parte  y quedan tareas pendientes para finalizar el sprint, se arremangue y las realice evitando así cuellos de botella. Hay que buscar la parte buena de la especializacion evitando que ocurra la negativa.

La semana que viene espero terminar la charla escrita.

Compartiendo los tomates

En el momento de escribir esto hay un anuncio de una compañía de telefono que dice algo así como “Cuando algo es así de bueno, hay que compartirlo”. Esto es lo que me ha pasado cuando he descubierto una aplicación que me ha parecido útil de verdad.

Sé que estoy escribiendo la charla de potenciación de equipos pero no puedo resistirme a hablar de esto. Además está muy relacionado con el tema. 😉

Hace tiempo ya que se viene comentando en el mundillo del desarrollo software acerca de la tecnica pomodoro, yo mismo escribí una entrada hace tiempo. Esta técnica recomienda hacer intervalos de 25 minutos de concentración y 5 de descanso. Tan sencillo pero a la vez tan dificil de hacer. Ya que esta técnica necesita de algo muy importante, que la gente que trabaje contigo respete tus pomodoros.

Hace más de un mes empecé a escribir (porque no encontré ninguna) una aplicación para gestionar pomodoros que permitiera ver si los compañeros están o no pomodoreando para no interrumpirles en mal momento. Pues me he enterado que esta aplicación ya existía. Se llama Cherrytomato y se puede encontrar aquí.

Esta aplicación se comunica con el skype, un invento más robatiempo que el teléfono. Cuando se empieza un pomodoro marca automáticamente el status de skype como “Do Not Disturb” y además pone como la frase del contacto algo como “Estoy ocupado hasta dentro de X minutos”. Más claro, agua. Please no molestar.

Algo aparentemente sencillo pero a la vez tan útil. Uno es capaz de ver qué compañeros estan pomodoreando para esperar a que terminen y tus compañeros ya no tienen excusa tampoco para romper tus pomodoros. Como funcionalidad extra, esta aplicación cuando terminas el pomodoro te da un gráfico de intensidad de uso del teclado y ratón, así como las aplicaciones que has venido usando durante el pomodoro. Una gracia.

Voy a seguir usandolo y espero que lo usen mis compañeros para obtener  en el equipo las dos ventajas principales de la técnica pomodoro (productividad y felicidad)

Integración continua. Convertir un problema en una ventaja

Vamos a ver si te suena estas frases:

– Preparando un paquete para instalarlo  “¿quien sabe dónde narices están los scripts de bases de datos?”
– Corrigiendo un bug urgente “¿por qué no me compila ahora este código?”
– Probando una funcionalidad recien implementada “¿de dónde saco lo que acabas de desarrollar?”
– Respondiendo una incidencia de soporte. “En mi máquina funcionaba correctamente”

Estos son los problemas tipicos que pueden ocurrir por una mala o muy laboriosa integración. Cada programador realiza su trabajo correctamente pero a la hora de juntar todas las piezas en un paquete de software que funcione ocurren estos problemas. Esa integración necesita un conocimiento especifico y la persona que la realiza se convierte en una caja negra, es decir, se sabe lo que hace pero no cómo lo hace.
La solución es convertir el conocimiento implicito de integración en un proceso automático realizado por una máquina dedicada. Como para ser ágiles necesitamos feedback lo más temprano posible, esta integración se va a realizar en cada cambio de codigo fuente, cada check-In de cualquier desarrollador.

En video stream networks tenemos un servidor dedicado que realiza las integraciones. En cada proceso de integración se realizan desde cero los siguientes pasos:
– Obtiene todo el codigo fuente del servidor (source safe 2005)
– Realiza una compilación de toda la solución (Visual Studio 2008 y 2010).
– Ejecuta los scripts de bases de datos (que está junto al proyecto en el servidor) creando siempre la base de datos desde cero.
– Ejecuta los tests automaticos, usando la base de datos recien creada
– Crea los ficheros que necesita (ficheros de lenguajes y configuración) a partir de los componentes recien compilados.
– Copia todos los ficheros resultantes en un directorio LastBuild de un servidor

Como me costó encontrar documentación de Cruise Control .NET, el software que usamos para la integración continua, voy a exponer y explicar un ejemplo de proyecto de integración de los que tenemos.

<!-- Empieza el bloque de un proyecto -->
<project name="vsnarchive4" webURL="http://localhost/ccnet">

	<triggers>
		<!-- Comprueba cada minuto el código fuente por si hay cambios -->
		<intervalTrigger /> 

		<!-- A las 11 de la noche siempre hace un build de todos los proyectos -->
		<scheduleTrigger time="23:15" buildCondition="ForceBuild" name="Scheduled" />
	</triggers>

	<!-- Bloque de control de código fuente. Usamos SourceSafe 2005 como control de código fuente -->
	<sourcecontrol type="vss" autoGetSource="true">
		<!--  Proyecto de SorceSafe -->
		<project>$/DesktopApplications/MultiPlatform/MultiPlatform</project>

		<!-- Usuario de sourcesafe. Hemos creado uno especial con permisos de lectura -->
		<username>builds</username>
		<password></password>

		<!-- Esto es importante para que lea los cambios. El lenguaje en el que se tiene el sourcesafe -->
		<culture>en-US</culture>

		<!-- Directorio donde esta la configuracion de sourcesafe. Normalmente en otro servidor -->
		<ssdir>\\servidor2\VSS\</ssdir>

		<!-- Directorio donde se descarga el codigo fuente y que va a usarse para compilar -->
		<workingDirectory>E:\vsn.net\vsnarchive4</workingDirectory>
	</sourcecontrol>

	<-- Lista de cosas a realizar paa hacer la integracion. Se ejecutan por orden -->
	<tasks>
		<!-- Compilacion con Visual Studio 2008 -->
		<devenv>
			<configuration>Release</configuration>
			<executable>D:\Desarrollo\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com 		</executable>
			<version>VS2008</version>
			<solutionfile>E:\vsn.net\vsnarchive4\Multiplatform.sln</solutionfile>
		</devenv>

		<!-- Pasos previos del testeo unitario -->
		<!-- Creamos desde 0 la BD de vsnarchive4 -->

		<exec>
			<executable>sqlcmd</executable>
			<baseDirectory>c:\windows</baseDirectory>
			<buildArgs>-iE:\vsn.net\vsnarchive4\Database\vsnarchive4DB_Creation.sql</buildArgs>
			<buildTimeoutSeconds>60</buildTimeoutSeconds>
			<successExitCodes>0</successExitCodes>

		</exec>

		<exec>
			<executable>sqlcmd</executable>
			<baseDirectory>c:\windows</baseDirectory>
			<buildArgs>-iE:\vsn.net\vsnarchive4\Database\vsnarchive4DB_Update.sql</buildArgs>
			<buildTimeoutSeconds>60</buildTimeoutSeconds>
			<successExitCodes>0</successExitCodes>
		</exec>

		<!-- Insertamos los datos necsarios en la BD para hacer los tests
		<exec>
			<executable>sqlcmd</executable>
			<baseDirectory>c:\windows</baseDirectory>
			<buildArgs>-iE:\vsn.net\vsnarchive4\MultiPlatform\Tests\ScriptsDB\Before.sql</buildArgs>
			<buildTimeoutSeconds>60</buildTimeoutSeconds>
			<successExitCodes>0</successExitCodes>

		</exec>	-->

		<!-- Fin de pasos previos del testeo unitario -->

		<!-- Tests unitarios con NUnit -->
		<nunit path="D:\Desarrollo\NUnit\2.4.8\bin\nunit-console.exe">
			<assemblies>
				<assembly>E:\vsn.net\vsnarchive4\UIWPF\bin\Release\vsnarchive4.exe</assembly>
			</assemblies>
		</nunit>

		<!-- Pasos posteriores del testeo unitario -->

		<exec>
			<executable>sqlcmd</executable>
			<baseDirectory>c:\windows</baseDirectory>
			<buildArgs>-iE:\vsn.net\vsnarchive4\MultiPlatform\Tests\ScriptsDB\After.sql</buildArgs>
			<buildTimeoutSeconds>60</buildTimeoutSeconds>
			<successExitCodes>0</successExitCodes>

		</exec>
		<!-- Fin de pasos posteriores del testeo unitario -->

		<!-- Creamos los ficheros de configuración a partir de los assemblies -->
		<exec>
			<executable>vsnarchive4.exe</executable>
			<baseDirectory>E:\vsn.net\vsnarchive4\UIWPF\bin\Release\</baseDirectory>
			<buildArgs>/CreateConfig</buildArgs>
			<buildTimeoutSeconds>10</buildTimeoutSeconds>
			<successExitCodes>0,1,3,5</successExitCodes>
		</exec>

		<!-- Creamos los ficheros de lenguaje a partir de los assemblies -->
		<exec>
			<executable>vsnarchive4.exe</executable>
			<baseDirectory>E:\vsn.net\vsnarchive4\UIWPF\bin\Release\</baseDirectory>
			<buildArgs>/CreateLang</buildArgs>
			<buildTimeoutSeconds>10</buildTimeoutSeconds>
			<successExitCodes>0,1,3,5</successExitCodes>
		</exec>

		<!-- Copiamos los scripts de BD a la carpeta origen del deploy -->
		<exec>
			<executable>cmd</executable>
			<baseDirectory>c:\windows</baseDirectory>
			<buildArgs>/C xcopy E:\vsn.net\vsnarchive4\Database\*.* E:\vsn.net\vsnarchive4\UIWPF\bin\Release\Database  /e /y /I</buildArgs>
			<buildTimeoutSeconds>10</buildTimeoutSeconds>
			<successExitCodes>0,1,3,5</successExitCodes>
		</exec>

		<!-- Fin de las tareas de integracion. Falta el deploy en sí mismo -->
	</tasks>

	<!-- Fin de la integración. Qué hacemos con lo que hemos generado -->
	<publishers>
		<!-- Los logs de resultado al subdirectorio log -->
		<xmllogger logDir="log" />

		<!-- Envio de emails de los resultados. A mi como buildmaster un email siempre con el resultado -->
		<!-- y al programador responsable cuando algo se ha roto y cuando se ha arreglado -->
		<email mailport="25" mailhost="mail.myworkplace.es" includeDetails="True" mailhostUsername="builds@myworkplace.es" mailhostPassword="pass">
			<from>builds@myworkplace.es</from>
			<users>
				<user name="Jorge" group="buildmaster" address="jorge@myworkplace.es"/>
				<user name="Antonio" group="developers" address="antonio@myworkplace.es"/>
			</users>
			<groups>
				<group name="developers">
					<notifications>
						<NotificationType>Failed</NotificationType>
						<NotificationType>Fixed</NotificationType>
					</notifications>
				</group>
				<group name="buildmaster" >
					<notifications>
						<NotificationType>Always</NotificationType>
					</notifications>
				</group>
			</groups>
		</email>

		<!-- Deploy del directorio especificado. Borra el directorio antes de copiar -->
		<buildpublisher>
			<cleanPublishDirPriorToCopy>true</cleanPublishDirPriorToCopy>
			<sourceDir>E:\vsn.net\vsnarchive4\UIWPF\bin\Release\</sourceDir>
			<publishDir>\\servidor\Distribuciones\vsnarchive4\Win32\LastBuild</publishDir>
			<useLabelSubDirectory>false</useLabelSubDirectory>
			<alwaysPublish>false</alwaysPublish>
		</buildpublisher>
	</publishers>

</project>

Sólo falta instalar el programita cliente que se conecta al servidor y asociar una musica cuando alguien ha roto el build. En mi caso si se rompe el build suena la Marcha Imperial de Dark Vader. 😉

Un recorrido por el manifiesto ágil

Hace poco vi un video de una conferencia de Martin Fowler sobre por qué la agilidad funciona. Expone entre él y Neal Ford varias tecnicas agiles como ejemplo de por qué estan añadiendo valor a las empresas que lo usan. Este vídeo  me dió la idea de exponer un listado de tecnologias denominadas ágiles relacionadas con los 4 postulados del manifiesto ágil. Empecemos por el primero.

Individuos e interacciones sobre procesos y herramientas

Este es el que más tiene que ver con el nucleo duro del desarrollo software, el equipo de desarrollo y su trabajo diario.. Cómo empezó a descubrir Fred Brooks en el Mitico Hombre Mes, un desarrollador no se tiene nada que ver con una máquina de producción en serie que se puede establecer un rendimiento fijo. Ese rendimiento depende de mil factores y uno muy importante es su comunicación con el resto de integrantes del equipo. Es importante que cada miembro del equipo esté motivado y tenga un compromiso proveniente de él mismo hacia el equipo y su proyecto.

En el libro Management Rewired de Charles S Jacobs, define como el grupo de producción perfecto el formado por un pequeño numero de personas (5-7) autonomos cuya subsistencia depende  del proyecto que tienen entre manos. Segun Jacobs, esta organización fue la que funcionaba cuando habia grupos de herreros, de carpienteros, de ganaderos… Esto mismo  es lo que plantea Scrum, un grupo de 5-7 personas autonomas. Si se añaden más personas se complica la gestión por una necesidad excesiva de comunicacion y con menos personas no se consigue la sinergía que se genera con un equipo multidisciplinar motivado.
La agilidad plantea la comunicación de tal modo que sea lo más eficiente posible. Las reuniones se establecen para que se interambie la información necesaria para seguir trabajando sin  gastar más tiempo que el estricatamente necesario. Cada reunión tiene definidos un objetivo y un timebox, es decir, un tiempo máximo que una vez terminado se da por finalizada la reunión. La comunicación offline mediante un sistemas de tarjetas, por ejemplo,  aportan un elemento  concreto y una ubicacion (al lado del tablero) para realizar decisiones. El pair programming es otro elemento interesante de interacción entre desarrolladores. Es muy dificil,sino imposible, medir la productividad de una pareja de programadores comparado con lo que produciría uno sólo. Es por esto por lo que la medida en la que mejora el resultado de un desarrollo no es facilmente cuantificable pero es patente en el resultado. En el vídeo que comento al principio del post, Martin Fowler comenta que una pareja que trabaja en el mismo codigo trabaja como un cerebro con sus dos lados activos a la vez. El que está con el teclado usaría la parte logica y matematica del cerebro (el izquierdo) para resolver el problema de código que tiene entre manos y el desarrollador que está al lado, con su visión más amplia aporta el lado más creativo  (el derecho).
El entorno es tambien importante para esta comunicación. El entorno de trabajo debe favorecer la comunicación de todos con todos de modo visual cara a cara. Se descartan los cubiculos y se intenta crear un entorno en el que la información del proyecto esté visible en todo momento para todos y se promueva la creatividad.

Software funcionando sobre documentación extensiva

Los programadores no somos buenos escritores de narrativa. De hecho normalmente somos muy malos en la expresión escrita (yo admito que lo soy). La documentación hay que usarla como herramienta para un proposito concreto. Un diseño de clases basico o un diagrama de interacción entre clases puede ayudar a entender un código y saber dónde hacer un mantenimiento de modo más optimo. Ese diseño, dentro de poco tiempo qudaría obsoleto a no ser que se dedique su tiempo en mantenerlo al día.  Sin embargo, lo que más importa es tener un pedazo de software que pueda aportar valor al cliente. A partir de él se puede generar la documentacion mediante analizadores de código y metadata pero no al reves. Al realizar distintos niveles de test se ofrece un testeo cada vez más amplio. Empezamos con un testeo de los métodos de una clase mediante el testeo unitario en el PC del desarrollador. Seguimos con un test de integracion mediante un build centralizado que testea todo el codigo de los desarrolladores juntos. Al final del sprint hay un test de aceptación realizado por el product owner en el que se ven posibles problemas y se añaden sugerencias.

Colaboración con el cliente sobre negociación contractual

En Scrum se define un rol muy importante que es el  Scrum Owner. Esta persona (unica persona) debe hacer lo posible por conocer el negocio y aportar su conocimiento al equpo de desarrollo entre incrementos de producto. El nuevo requerimiento a mitad de proyecto no es una incidencia que haya que intentar evitar sino que es algo que le dará  valor añadido al producto por lo que hay que aceptarlo. El sistema de gestion de proyectos iterativo es la mejor manera de ir adaptando el software a las necesidades del cliente segun se va dando cuenta de ellas. La demo que se realiza al  final de sprint es para él cliente y/o el Product Owner y todos los que puedan aportar ideas. El cliente no se siente atado por haber firmado un documento de requierimientos ni el equipo tiene que modificar todo el proceso rompiendo el proyecto a mitad por un requerimiento inesperado.

Respuesta ante el cambio sobre seguimiento de  un plan

El permirir introducir cambios a mitad de desarrollo tiene sus métodos, no es un simple ASM (A Salto de Mata). No se hace un diseño complejo al inicio sino que se hace el diseño más simple que cumpla lo necesario por el test. A muchos desarrolladores nos gusta pensar  a lo grande e intentar preveer todos los casos pero esto es algo que normalmente provoca que el proyecto se sobredimensiento. El código basado en ese diseño simple está lo suficientemente cubierto pro tests unitarios para poder refactorizarlo y adaptarlo a las nuevas necesidades. Se cambia la mentalidad de tenerlo todo previsto por la de intentar  tener toda la información (feedback) lo más pronto posible para reaccionar y adaptar si es necesario el proceso  Si hacemos un recuento de tipos de  feedback de más proximo al desarrollador a más lejano empezaremos por el compañero del pair-programming que nos indica un error en el que no hemos caido justo al teclearlo,el  unit-test que nos salta cuando la hemos cagado sin querer en cuanto damos a compilar, el build centralizado diario que nos muestra nada más llegar a la oficina que ha habido un problema de integracion, el kanban a la vista de todos para ver cuando alguien ha cambiedo de estado una tarea nos da la posibilidad de verificar ese cambio inmediatamente, la demo de final de sprint que nos verifica que ese incremento ha sido todo un exito.

Mi aportación a la técnica pomodoro

Voy dar mi pequeña aportación sobre una técnica que descubrí la semana pasada pero que considero un must-know para todos los desarrolladores de software, la tecnica pomodoro. Hay otros blogs como el de David Bonilla que ya lo explican (aquí o aquí y ahora también aqui) y además lo hacen con una gran calidad de expresión.

Más que una tecnica de gestion de tareas personales como el Autofocus , la tecnica pomodoro da las pautas necesarias para provocar un estado mental de máxima concentración llamado flujo. Pero bueno,.. empezamos por el principio.

¿A quién no le suena una típica mañana en la mente de un programador?

9:00 – Mmmm. Buenos dias… voy  a ver mi correo
9:30 – (Unos cuantos correos y webs despues) Voy a programar !!…
9:35 – No he cogido agua. Voy a por mi vaso.
9:36 – ¿Por dónde iba…? Ah sí….
9:45 – Un correo. Voy a mirarlo. A ver… Si, ya sé cual es el problema del cliente. No ha encendido el ordenador. Una respuesta concisa y educada.
9:50 – ¿Tenía ya el test unitario terminado?. Ah, no. que faltaba añadir este dato de entrada.
9:52 – Voy a servicio…

Después de muchas idas y venidas de nuestra saltarina mente, al final del día tenemos la tipica sensación de que no hemos parado pero que no hemos hecho nada productivo. Esto ocurre tanto a los programadores como a cualquier persona que tiene que realizar un trabajo en el que necesita una concentración mental, por ejemplo a los estudiantes. Hace una semana hice una charla sobre el método en la primera reunión del Agile Spain en Alicante y se apuntó la pareja de uno de los asistentes que era estudiante.

Estudiante era también el creador de la técnica Pomodoro, Francesco Cirillo cuando en 1992 vió que tanto él como sus compañeros de estudio no eran capaces de estar concentrados sin levantar la cabeza más de 10 minutos seguidos. Para intentar mejorar esta marca (10 minutos) usó un reloj de cocina con forma de tomate y lo programó 25 minutos para que le sonara cuando habia terminado su sprint de concentración. Se dió cuenta que era algo que funcionaba e investigó para depurar esta ya famosa técnica. Todos los detalles estan en su web oficial.

¿Serías capaz tu de estar 25 minutos seguidos programando/analizando/testeando/estudiando…. sin cambiar tu mente de asunto? Si lo consigues ¡Felicidades !. Seguramente  te habrás dado cuenta cuanta de que estas siendo productivo, que el trabajo avanza y es más, que estas empezando a disfrutar de tu trabajo. Este estado mental  es llamado flujo y es muy dificil de conseguir en circunstancias normales.  Lo normal es que al primer intento no consigas completar un pomodoro y que una de las dos tipos de interrupciones te ataque en mitad de uno.

Francisco Cirillo define como interrupciones internas las que tu mente te lanza (“hay que ir a por agua”, “vamos a ver ese email que nos han enviado”, “tengo pis”, “voy a llamar a mi chica”…). Las interrupciones externas son las que producen otros agentes externos, dicese jefes o compañeros (“tienes que ponerte en contacto con este cliente”, “¿me ayudas a corregir esto?”, “¿Qué piensas de esta decision de diseño?…”). La tecnica dice que esas interrupciones hay que anotarlas en una lista de tareas no previstas e intentar seguir con la mente enfocada en la tarea en cuestión. Puede parecer una utopía pero la mayor parte de las tareas pueden retrasarse hasta que estos 25 minutos terminen. Es importante demostrar a esos agentes externos que sus peticiones van a ser igualmente satisfechas, sólo que cómo máximo 25 minutos más tarde.

¿Qué pasa cuando suena el reloj y han pasado los 25 minutos? Pues anotas una crucecita al lado de la tarea en la que estás o que has completado y descansas. Te mereces un descanso de 3 a 5 minutos en los que puedes ir a por agua, al aseo, ver ese video  de youtube que te han enviado, mirar por la ventana,… Lo que quieras que no requiera concentración mental. Si eres un samurai total del pomodoro y completas ¡4 pomodoros!  sal a la calle, respira hondo y sientete orgulloso por haberlo conseguido mientras te tomas un café, te comes el almuerzo o lo que te dé la gana.Tienes de 15 a 30 minutos de descanso por tu alta productividad.  Te lo mereces.

¿Qué pasa cuando llega una interrupción que no puedes simplemente apuntarla e ignorarla? Pues que te han roto el pomodoro. Con una mezcla entre resignación y  pequeño cabreo, vuelves a poner el reloj en marcha y esos 25 minutos empiezan a contar. Quizá mejor suerte en el siguiente.

Puede parecer que con tanto descanso, se está uno tocando las bowlings mientras que el resto de compañeros no se levantan de su silla. Nada más lejos de la realidad. Todos lo que conozco que usan la técnica dicen que cuando en un día se han hecho más de 8 pomodoros (tarea algo idilica) sólo tienen ganas de meter la cabeza en un barreño de agua con hielo y las tareas de su kanban van pasando a completado a una velocidad absurda.

En el libro de la técnica (gratuita su versión online) indica cómo hacer anotaciones para ver el avance con el dominio de la técnica. Propone anotaciones con un simbolo las interrupciones internas y con otro las externas para intentar disminuir ese número cada vez. Tambien se puede guardar el numero de pomodoros completados e interrumpidos. Todo esto permite mejorarse día a día. Según mi propia experiencia, el conseguir más de 3 pomodoros completos el primer dia puede ser tarea ardua. Siempre hay que conseguir más pomodoros que el día anterior. Como dice David Bonilla en su blog ¡Protege tus pomodoros!.

Intenta juntar varias tareas relacionadas que puedan llenar un pomodoro. Si te sobra un poco de tiempo, dedicalo a revisar el trabajo que has realizado para completar los 25 minutos. Un pomodoro es indivisible.

Para los que conozcan Scrum, la tecnica del pomodoro me suena al concepto del sprint. En un sprint de Scrum, las tareas están definidas en un intervalo concreto (2-4 semanas) de tal modo que si llegan nuevos requerimientos, no se interrumpe el trabajo de ese sprint para adaptarlos sino que se espera al siguiente.

Se me ocurren varios hilos de investigacion que me parecen interesantes y espero poder dedicarle atención en breve:

  • Cómo aplicarlo al trabajo por parejas (Pair Programming). Este libro parece interesante. Intentaré echarle un vistazo.
  • Cómo aplicarlo al trabajo de un equipo scrum.
  • Cómo aplicarlo al TDD (¿se usan pomodoros distintos para la generación de test, para la codificación y refactorización?)
  • Qué relacion tiene entre la velocidad de un equipo ágil y el número de pomodoros que son capaces de completar. (Sé que hay alguien que lo está investigando pero me falta su nombre)

Espero poder ampliar y corregir este post. O quizé mejor, escribir otro para explicar alguno de los puntos que investigue.

Espero vuestros comentarios!!