Hace poco di un curso en la oficina de I+D de Video Stream Networks acerca de estimación por puntos. Ya me temía que iba a haber problemas porque el tema de la estimación siempre lo hemos considerado algo de pitonisas. Cuánto se iba a tardar en realizar un desarrollo, teniendo en cuenta que cambiamos con frecuencia de tecnología (c++, C#, javascript, …) además de usar nuevos frameworks, es practicamente imposible de estimar antes de empezar. El entorno de cambio constante en tecnologias de desarrollo que vivimos en nuestra empresa hace que nuestro sistema de trabajo lo consideremos Agil Extremo. La estimación por puntos nos va como anillo al dedo.

Una estimación en puntos se piensa sin tener en cuenta:

• La persona que lo va a desarrollar
• El lenguaje de programación que va a usar
• La familiaridad con la tecnologia a usar por parte del desarrollador

¿Qué se consigue aislando todos estos factores y otros afines? Lo que se obtiene es una representación concreta de una tarea que se puede medir en relación de otras tareas. Por un lado tendríamos este tamaño en puntos que es lo estimado de la tarea y por el otro todos los posibles factores que afectan al tiempo de completar la tarea pero que son muy dificiles de predecir.

.

Al principio del sprint se estiman los tamaños de todas las tareas que se van a realizar en ese sprint. El conjunto de los factores inestimables son los que van a determinar cuantos puntos se van a realizar al finalizar un sprint, es decir, van a marcar la velocidad del equipo.

Una vez hemos terminado un sprint tenemos  la cantidad de puntos que hemos completado. Esta ha sido la velocidad para ese sprint y probablemente no coincidirá exactamente con la velocidad del siguiente. Cómo mínimo se recomienda de tres a cinco sprints para poder tener un rango de velocidades y poder usarlo para estimar el trabajo del equipo más a largo plazo.

La retrospectiva es el momento de hablar de estos factores que han afectado a la velocidad. Lo que ha impedido que se realicen más puntos se intenta eliminar para los siguientes sprints y lo que ha mejorado la productividad se intenta repetir. De este modo se intenta que sprint tras sprint, se aumente la velocidad del equipo.

Como verás estamos hablando una cantidad de puntos variable para un periodo fijo que es el sprint. La estimación por puntos tal cual lo hemos visto aqui no sirve para poder tener un compromiso de cuando se terminarán un número fijo de tareas. Para esto existen otras técnicas que no veremos hoy. 🙂

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

En un proyecto tradicional sólo hay un intento. El desarrollo ha pasado por sus distintas fases (analisis, diseño, programacion, testing) y cuando estan todas las piezas se juntan y se mandan al cliente. Todos los problemas de integracion se encuentran y resuelven al final o casi al final de todo el proceso.

A mi entender, la agilidad intenta convertir un gran problema que ocurre puntualmente  en una simple molestia rutinaria. Esto ocurre con la integracion continua y esto veo que ocurre con las demos al final del sprint.

– Obliga a los desarrolladores a mirar todo lo que se ha hecho desde el inicio del sprint y verificar que efectivamente sigue funcionando
– Cuando se desarrollan librerias cliente junto con aplicaciones, es momento de cerrar versiones de esas librerias
– Si el sistema de integracion continua no está al 100% es el momento de juntar todos los ficheros necesarios en paquetes funcionales.
– Los desarrolladores son los que van a mostrar el software por lo que tienen una atención especial en que todo funcione
– El tema estético se mira a fondo. Esos iconos que no se ven bien, ese texto que está mal escrito…. En condiciones de desarrollo normal no sé por qué pero nos solemos centrar más en hacer las funcionalidades nuevas que en temas esteticos pero cuando hay que enseñarlo la historia cambia.

A nivel informativo, estas demos son tambien muy utiles. Como dice el manifiesto: el software que funciona es el mejor medio de enseñar el avance. Esto implica que:

– La gente no implicada en desarrollo ve en qué punto está el desarrollo y su forma, usabilidad,… y puede aportar ideas
– Los propios desarrolladores que han hecho librerias concretas es posible que no hayan visto el software completo con su interfaz hasta este momento.
– Los problemitas esteticos saltan más a la vista que en el momento de desarrollo
– El famoso «efecto demo». No hay nada como enseñar algo para que ese algo falle. Murphy tendrá algo que ver seguro. Pero claro, mejor que ocurra en la demo que una vez vendido, cerrado el proyecto y usandolo el cliente.

El mejor momento para hacerlas es el viernes por la mañana. Es momento de tensión pero una vez terminada, el lunes se empieza sintiendose realizado y con ganas de empezar el nuevo sprint. Recomiendo usarlo para hacer algun cursillo interno despues de la demo. Tiene que ser un dia distinto e intentar hacerlo más distendido que los del resto del sprint. Ya se sabe, si se hace sprint continuamente se convierte en un jogging.

Donde trabajo sólo hemos hecho un par de sprints completos con demo incluida pero estamos viendo la utilidad de estos ciclos y los iremos mejorando poco a poco.

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.

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!!

Hola

Este no es una entrada que tenga que ver con la tecnología sino algo más casero. Voy a hablar de un sistema muy potente para todo aquel padre/madre que quiere que su hijo/a sea bilingüe de un idioma distinto al que se habla en casa. El único requisito es que al menos uno de los padres tenga un nivel aceptable de ese idioma. No importa que no sea perfecto. El mio no lo es.

El «truco» se me ocurrió en una charla para el colegio de mi hijo. En la Comunidad Valenciana, para promover la enseñanza en valenciano, la generalitat organiza charlas en las que se intenta «vender» a los padres las bondades del bilingüismo en valenciano en las escuelas. En una de las partes, la ponente explicaba que el niño no tiene confusión entre  los idiomas porque en la escuela tiene un contexto y en casa tiene otro. El niño asocia un contexto distinto a cada idioma aprendiendo los dos en paralelo sin cruzarlos. Una de mis pasiones es la neurología y cómo el cerebro funciona para los procesos del día a día. Aprendí hace poco por ejemplo que Walt Disney tenía tres ubicaciones distintas para distintas funciones cerebrales que usaba en su trabajo (el creativo, el realista y el critico).  También es importante el contexto cuando hablamos de rendimiento en exámenes, peticiones de aumento de sueldo, etc…

En ese momento pensé: «¿Qué lugar de la casa podría usar para que fuera un contexto distinto y poder usar ahí un idioma distinto? La respuesta fue: «el baño».

Desde ese momento (semana del 15 de Abril del 2010), empecé a hablar sólo en Inglés con mi hijo durante el tiempo de baño . Este tiempo es un rato que aprovecho para jugar con él con todos los muñecos que tiene dentro (cada vez trae más). El juego es el vehículo que uso para elegir qué vocabulario usar. A los niños les gusta jugar normalmente a los mismos juegos durante un par de días seguidos pero van cambiando frecuentemente a lo largo del tiempo. Esto hace que el vocabulario y el tipo de expresiones a usar en ingles no están limitadas sino que puedan ir progresando y tampoco sea muy extensivo al principio. En cuanto el niño/a tiene ya la ropa puesta y salimos por la puerta del baño, automáticamente volvemos a cambiar el idioma a español. En mi opinión considero más importante que entienda las estructuras del inglés que el que le vaya preguntando traducciones concretas por eso hablo y hablo en inglés sin importar si entiende el 100% de lo que digo. Cuando hay palabras nuevas que sé que no sabe, le traduzco en español o mejor aun, se lo muestro, y repito la misma frase en ingles sin perder el hijo del juego en curso.

Las primeras dos semanas, el niño se reía con lo que hablaba y se pensaba que estaba diciendo palabras sin sentido. Me imitaba con expresiones como «bala bala poco poco tuu».Lo siguiente fue reconocer el nombre de juguetes que usábamos frecuentemente. El tiburón (the shark), el pato (the duck),… Cuando le hacía una pregunta, el niño notaba que la entonación era de una pregunta y siempre me respondía «si», sin importar que le hubiera preguntado un cómo, cuando o un por qué.

Poco a poco fue aprendiendo preguntas básicas como el «Where». A preguntas como «where is the shark?» me respondía señalando el muñeco. Las palabras referentes a la ropa ya las conocía («One shoe». «The other shoe», … ) ya que al vestirlo recito todas las prendas de ropa mientras se las pongo.

En unas pocas semanas después el niño ya sabia que lo que hacíamos era hablar en ingles. Cuando entramos en el baño siempre me pide que hablemos en ingles. Hay veces que los dibujos animados me los pide en ingles y lo pongo gustosamente. En cuanto me pide en español lo vuelvo a cambiar. Hay que tener claro que tiene que ser un juego para él y no hay que agobiarlo. Lo único obligatorio 100% en ingles es la hora del baño y en el momento que note que se canse también haré un descanso. Ya entiende preguntas como el «Why» y me responde «Porque….»En las frases en las que hay una palabra que no entiende, me pregunta por ejemplo «que es ugly?. Esto quiere decir que entiende la frase pero le falta esa palabra para entender qué estoy diciendo.

Actualmente (ya hace dos meses) aun me sorprende traduciendome palabras que capta de los dibujos animados, cuando los ponemos en ingles. Incluso hay veces que capta una palabra en ingles antes que yo 🙂 Sigue hablandome en español en el baño excepto el nombre de los juguetes que va cambiando del español al ingles. No me imagino qué nivel puede tener si seguimos hablando en ingles durante un año o dos. Como he dicho antes mi inglés no es perfecto pero estaría encantado que lo alcanzara en ese plazo.

Considero que el sistema es super potente y seguiré usándolo y espero seguir sorprendiendome con los resultados. Lamentablemente, unas de las carencias más importantes del sistema educativo, al menos en la Comunidad Valenciana, es el nivel del inglés con el que salen los niños al terminar el colegio. Se gastan ingentes cantidades de dinero en promover el valenciano haciendo que los niños salgan  con un buen nivel que les será muy útil casi únicamente para hacer oposiciones en la propia Comunidad Valenciana pero no en el ámbito privado y mucho menos en el internacional. Como tampoco hay profesores suficientes con un nivel de inglés como para dar docencia en ese idioma, volvemos al principio igual que  la clásica pescadilla que se muerde la cola.

Espero que este sistema le sea útil a muchos padres más. A mi me lo esta siendo y espero que a mi hijo le sea muy provechoso en el futuro.Espero vuestros comentarios.

Un saludo a todos los papas y mamas que me están leyendo.

Actualización a 9 de Septiembre. Casi 6 meses hablando inglés en el baño. El niño ya dice frases sueltas. «Did we finished?», «Let’s go!», me llama «daddy» de vez en cuando,… Creo que conoce ya cerca de 50 palabras incluyendo sustantivos, verbos, colores, numeros,… Sigo sabiendo que me entiende perfectamente cuando incluyo una palabra nueva. Inmediatamente me pregunta qué significa. Ha aumentado su interés en el inglés ya que me pregunta fuera del baño cómo se dice tal o cual palabra en inglés. Tambien debo dar gracias al canal Baby TV que tienen sólo doblado el 20% de la programación (y para las siestas viene muy bien) porque canta algunos trozos de canciones en inglés. Seguiré informando…

Estoy leyendo un pequeño libro de Tom Peters. Está definido como el gurú de los gurús en temas empresariales. Ha escrito libros como «En busca de la Excelencia»  y «Triunfar sin que tu jefe te estorbe» de ediciones nowtilus. Entre las muchas cosas que defiente de las que ya hablaré (espero) en un futuro post, habla del concepto «Preparados, ¡FUEGO!, apunten…». (Ready, FIRE!, Aim en inglés). Lo que defiente en estas tres palabres es el  actuar antes de tener todo definido. Preparar un poco, actuar y mejorar después.

Aplicandola a la creación de software se puede aplicar en varios ámbitos, todos relacionados con la agilidad.

Desarrollo: Preparados, ¡FUEGO!, apunten… Prepara el test, haz que funcione, refactoriza… En esto se basa el testeo unitario y el Test Driven Development. Este es el ritmo más básico en el desarrollo software. Con estos pequeños pasos se realiza software que funciona con baja probabilidad de producir bugs.

Analisis: Preparados, ¡FUEGO!, apunten… Analiza un poco, implementa, mejoralo… En ocasiones no se puede hacer un analisis completo, sobre todo cuando el ámbito del problema es muy abstracto y/o complejo. En esos casos, se define una ventana temporal para el analisis, digamos 15 minutos. Si el tiempo llega a su fin se elige la mejor opción barajada hasta el momento. Una vez esté implementado ya se tiene un ambito más concreto y un elemento sobre el que trabajar que se puede ir mejorando mediante refactorización.

Gestion del proyecto: Preparados, ¡FUEGO!, apunten… Pequeña planificación, pequeña implementación, revisión….  Esta es la base del desarrollo iterativo usado por ejemplo en SCRUM. Se elige un conjunto de requerimientos, se implementan y se revisa lo implementado. A partir de un prototipo o una implementación parcial se puede obtener un software mucho más completo y preciso que haciendolo todo a la vez.

Todo esto que hemos visto proporciona una motivación y unas herramientas para una acción rápida y efectiva en un ambito complejo. El detenerse para tener todo claro,analizado y cerrado podría significar un cambio del entorno o peor aun,  la perdida de la oportunidad de realizar el proyecto.

Hace ya unas semanas que lleva una pizarra de etiquetas que puse en un sitio muy visible (de camino a los aseos) en la oficina donde trabajo. Quisiera explicaros un poco el funcionamiento y las ventajas que he observado hasta ahora.

Se llama pizarra Kanban . Hay muchas variaciones. Scrum Alliance propone una etiqueta para historia de usuario y otras etiquetas para las tareas de esa historia de usuario. El que he puesto tiene 2 columnas y 3 Filas:

En cada celda de la tabla habrá de 0 a varios post-its indicando proyectos en los que estamos. Los temas de soporte no hace falta meterlos aqui porque ya se gestionan en la web que tenemos. De todos modos si hay algo de soporte que implica un seguimiento concreto se puede meter para que se sepa en tejado de quien está. Las tareas pequeñas de menos de un dia no hace falta incluirlas y se considera ruido.

Un proyecto software tipicamente tendrá este circuito:
Desarrollo/Sin empezar –> Desarrollo/En Curso –> Testing/Sin empezar –> Testing/En curso –> Testing/Completado

El movimiento de las etiquetas lo hará la persona responsable para esa función. Tipicamente los desarrolladores moveran en la columna de Desarrollo y los del area tecnica lo harán en la columna de Testing. Todos los que estan implicados en ese proyecto pueden moverlo. Si hay discrepancias, enseguida se verán y se solucionarán.

En una etiquetas se puede escribir el nombre de la tarea y la fecha de inicio.
Si a una etiquetas se le quiere indicar información añadida temporal, (por ejemplo la tarea dentro de ese proyecto que hace falta para que se complete, necesidades especificas,… )se puede adjuntar una mini-etiqueta. Dado que no he conseguido pegar las mini-etiquetas dentro de la etiqueta grande de la tarea con el propio pegamento, lo he solucionado con unas pinzas pequeñas que las sujetan.

Ventajas del sistema:

• Visibilidad global del trabajo de toda la oficina. Todo el mundo que ve la pizarra ve claramente qué se está moviendo y como está de camino a los aseos es paso obligado. 😉
• Concretitud de la cantidad de proyectos. En ocasiones no tenemos constancia de las cosas que se estan haciendo en un departamento y puede parecer que hay muchas más o muchas menos de las que en realidad hay. El tablero es una vision realista de la carga de trabajo.
• Decision a la hora de dar un proyecto como completado. Cuando alguien pasa algo de en curso a completado lo hace a la vista de todos y esto conlleva a que se asegura de que realmente no queda nada por hacer. Esto evita el tipico problema del 85% completado.
• Cuando hay varios implicados en un proyecto, si uno de ellos mueve la tarea a completado y otro no está de acuerdo enseguida se verá y se llegará al consenso para decidir si el proyecto está completado o no.
• No se cogen más proyectos hasta que todo lo que está en curso no se haya completado. Para evitar la saturacion de tareas en curso, normalmente se motiva el completar lo que se tiene por terminar antes de empezar algo nuevo. En algunas implementaciones de Kanban incluso se define un número maximo de elementos que pueden estar en curso.
• Claridad en lo que está en el tejado de un departamento o en el otro.

El objetivo es que sea una herramienta que nos ayude a todos más que una burocracia. Si se ve que no se mantiene al día o que no ayuda en nada pensaré en quitarlo pero por el momento parece que ya esta dando frutos. Es importante la experimentación para intentar sacarle el máximo jugo. Si descubro usos nuevos o variaciones las iré actualizando esta entrada.

Un saludo.

Hace un poco más de un mes mi madre me dejó un libro de Lincoln Child llamado «Armonia Perfecta». Trata de una empresa llamada Eden que ofrece servicios de búsqueda de la pareja perfecta. Esos servicios cuestan 24.000 dolares y a base de una serie innumerable de tests psicologicos y de otros tipos y un super-ordenador con complejos algoritmos de inteligencia artificial va combinando los «especimes» hasta que encuentra una pareja lo más compatibles posible.
Yo, como ingeniero informatico pensé enseguida la viabilidad de algo parecido. Esta claro que el libro es muy peliculero pero quizá se pueda hacer algo parecido con muchos menos recursos. Y me puse manos a la obra.
Encontré en Facebook la plataforma perfecta para la aplicación. La gente puede darse de alta y lo primero que tiene que hacer es introducir sus parametros de busqueda (edad, sexo y localizacion geografica). Cada poco tiempo incluiré nuevos tests para que intente conocer más el perfil de cada persona: gustos, personalidad, hobbies… Y cuando haya suficiente gente en el sistema, empezaré una busqueda por semana. Buscará las mejores coincidencias en entorno local (20 km), cercano (40 km) y lejano (100 km) indicando cual es el mejor porcentaje de compatibilidad encontrado. Cada persona puede entonces elegir una de los resultados y concertar una cita. Si ambas partes estan de acuerdo se sugiere un sitio en el que se encontrarán fisicamente.
A cualquiera que esté interesado en encontrar su pareja perfecta en facebook sólo tiene que entrar en Eden y esperar que empiece a dar resultados. Todo el mundo está invitado.

Llegado a este punto algunos lectores podran preguntar ¿quien es este tio que habla de agil y scrum? Realmente no me considero un experto en este tema sino todo lo contrario. Voy aprendiendo día a días las bondades de todo lo que puede aportar las metodologias agiles. Hace ya más de un año que me decidí investigar lo máximo posible todas las herramientas que se puedan usar para la gestion de proyectos. Empecé mirando el tema de la certificación PMP del PMI. Para esto se necesitan unos cuantos años demostrables de experiencia como Project Manager así como un numeros de creditos en cursos y un examen. Tambien miré el tema de certificar los procesos con CMMI. Un compañero de donde trabajo estuvo involucrado en una metodologia CMMI Nivel 5. Meternos en eso parecía un camino imposible. Despues apareción Scrum y las metodologias agiles. Se basaban en asumir que las tecnologias con las que se va a hacer un desarrollo pueden no ser conocidas y algo que se estima en 3 dias puede llevar 30 (al fin alguien que nos entendía).
Sin embargo siempre he visto esos mundos como opuestos. PMI certificando a jefes de proyecto en unas metodologias concretas y lineales, CMMI como certificadora de procesos y por otro lado, la propuesta agil que es vista por muchos como desarrollo sin control. Sin embargo todos estan confluyendo para dar cabida a proyectos cada vez más complejos, con tecnologias emergentes de las cuales los clientes cada vez entienden menos por lo que sus requerimientos son menos concretos.
Por un lado CMMI y Scrum estan conviviendo perfectamente. Los propios del SEI en este documento afirman que el CMMI sólo indica los requerimientos de un proceso sin embargo las metodologias agiles indican en cómo se puede cumplir esos requerimientos. De hecho existen pruebas de empresas que cumplen el CMMI Nivel 5, ¡sí, el nivel 5! usando Scrum . Sin embargo, he oido recientemente en podcasts de scrummanager que no es camino fácil. Si se quiere obtener el CMMI sólo por la marca, se puede automatizar con scripts la generacion de la documentación necesaria mientras se sigue trabajando de un modo ágil.
PMI y Agil estan tambien haciendose amigos. Se acaba de abrir una comunidad del PMI en la que se abarca todo lo relacionado con las metodogias agiles. ¿Estamos viendo el principio de una bonita amistad?
Objetivo que me planteo a ver cómo va: Scrum -> CMMI Nivel 2 -> PMP ¿Será posible? parece facil alcanzar el CMMI nivel 2 usando metodologias agiles pero.. ¿podré tener experiencia demostrable suficiente para el PMP dentro de unos años?
Ya iremos viendo. Mientras, sigo aprendiendo y compartiendo…
Un saludo a todos