Category Archives: Agile

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.

Anuncios

Cosas que me llevo en la maleta del CAS2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Estimación por puntos explained

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

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.