Tag Archives: agil

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.

Reflexiones del CAS 2011. Oda a la HUMILDAD del Agilista

He pasado dos días increíbles en la Conferencia Agile Spain 2011. Felicidades tanto a la organización como a todos los ponentes por la calidad de sus charlas. Después de 24 horas y un par de reflexiones hay unas cosas que me gustaría compartir.

Lo que más me ha sorprendido es la capacidad de reírnos de nosotros mismos que he visto como común en todo agilista que ha asistido. Tanto los ponentes de las keynotes como Rainsberger  que se ríe de su nivel de español; los ponentes de las charlas como Enrique Comba se reía de si mismo cuando apareció como un mega-comercial psicodelico y David Bonilla que lo hace como nadie y mostró que en Atlassian eso es incluso una filosofía de trabajo. Todos y cada uno de nosotros tenemos gran capacidad de reírnos de nosotros mismos y para tener esa capacidad hay que tener otra que es casi más importante, la HUMILDAD. Sí, lo he escrito con mayúsculas.  No porque lo diga gritando sino porque hay que darle a la palabra la importancia que se merece.

Los agilistas tenemos la humildad suficiente para decir: “Sí. Cometemos errores programando, por eso lo primero que hacemos es el test”

Los agilistas tenemos la humildad suficiente para decir “Sí. Es posible que no entendamos bien lo que nos pides que te desarrollemos, por eso te lo vamos a enseñar lo antes posible y así nos lo puedes rechazar aun cuando estamos a tiempo”.

Los agilistas tenemos la humildad suficiente para decir “No. No podemos llegar con todo lo que nos pides en la fecha indicada, por eso vamos a ir entregando lo más importante paulatinamente. Por favor, no insistas en tenerlo todo.  Si lo haces te haremos un producto de baja calidad”

Es posible que el  resto del mercado del desarrollo del software  diga que sí. Que sí que puede hacer todo lo que se pide en una calidad indiscutible y por supuesto en la fecha que necesita el cliente. Ese tipo de gente que vende desarrollo de software normalmente no se ríe de si misma y va siempre en trajes negros con gafas oscuras y pelos pincho (¿os suena?). Pronto hablaré del traje de negocios, lo que significa, lo que comunica por qué hay que evitarlo. Una vez me dijeron que si se va con traje a ver al cliente se puede cobrar más. Los clientes actualmente confían más en la profesionalidad del propio traje, da igual quien lo lleve. Espero que pronto cambie esa mentalidad y realmente se confíe más en gente que suele ir con camisetas de Spiderman. Esa gente que gasta su dinero y su tiempo en hacer su trabajo lo mejor posible y dar el máximo valor. Esa gente que se va a sentar al lado del cliente a ver cómo trabaja desde el primer momento y ofrecerle lo que realmente necesita.

En la conferencia he aprendido que ese cambio de mentalidad es posible y es necesario. Necesario para que España y el mundo salga de todas las crisis. Hagamoslo realidad entre todos y extendamos esta visión.

“Maduramos el día en que nos reímos francamente de nosotros mismos.”

Albert Einstein

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.

Potenciación de equipos (parte I)

Esta es la primera parte de una charla que di en la reunión e Mayo del Agile Alicante.

Parte I. Un poco de historia.

La primera necesidad de organizar un grupo de cientos o miles de personas fué en el ámbito militar. Era inviable que un general coordinara por sí mismo a todo el contingente por lo que hacía falta crear algun tipo de jerarquía. Ya en el ejercito romano, cada mando sólo daba ordenes a un máximo de 10 personas que a su vez cada uno daba a otros diez y así hasta llegar a todos los legionarios. Así surgen cargos como el decurion (10 legionarios) y el centurión (10 decuriones = 100 legionarios). La estructura jerarquica era más que necesaria. Sin embargo la comunicación puede alterarse  cuando atraviesa un nivel jerarquico, igual que ocurre en el juego del telefono loco cuando se pasa un mensaje de persona a persona.  El ejercito resuelve este problema con una diciplina estricta. El mensaje es transmitido y ejecutado palabra por palabra sin posibilidad de analizarlo ni modificarlo.

El auge del ferrocarril provocó  la necesidad de coordinar miles de personas en un fin común en el mundo empresarial. Pensilvania Railroad, por ejemplo tenía a más de 100.000 personas empleadas en distintos lugares del pais. Todas estas personas necesitaban coordinación y control. Harrington Emerson adaptó las estructuras militares al mundo de la empresa. Lo más importante en este tipo de organización es el contron en los trabajadores, no en el modo en el que el trabajo es realizado. Además, cada función o departamento se convierte en un feudo en sí mismo. Realiza su trabajo con una mínima comunicación con el resto de departamentos. El resultado del trabajo es “lanzado” de departamento a departamento, y acaba variandose respecto a lo solicitado si se encuentran problemas en las fases anteriores o es el jefe el que tiene que resolverlos. La motivación de los trabajadores en este tipo de organizaciones suele basarse en gran medida en el salario, siendo un problema a medio y largo plazo. Los mandos intermedios normalmente están bastante limitados por su mandos superiores y no tienen gran capacidad de decisión respecto a la gente que llevan.

Hay muchos mercados que necesitan un tipo de estructura más dinámica. Un tipo de estructura que responda a un proceso de selección natural. Si cada elemento realiza bien su trabajo es recompensado por el cliente sino no es requerido más. El foco se gira hacia el cliente completamente. Si un elemento del equipo necesita reciclarse y adaptarse para nuevas necesidades del mercado lo hará. Este tipo de organizaciones fue muy usada a mediados del siglo 19 en los Estados Unidos. Las formaban pequeños emprendedores autonomos que se contratan unos a otros para dar una mejor respuesta al cliente. Así por ejemplo el propietario de las ovejas contrataba al mejor esquilador, despues al que mejor trataba la lana y de este modo  realizaba un producto de gran calidad para el mercado.

En la parte 2 veremos una descripción de qué es un equipo multidisciplinar y qué necesidades tiene.

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

Maldita demo, bendita demo

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.

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

Preparados,¡ FUEGO !, apunten…

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.

Pruebas con tablero Kanban

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:

DESARROLLO TESTING
SIN EMPEZAR
EN CURSO
COMPLETADAS

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.