Tag Archives: gestion de proyectos

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.

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.

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.

CMMI + PMI + Agile + Scrum ¿Utopia?

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

Management rewired para PMs o Scrum Masters

Hola

Por fín terminé el libro “Management Rewired” de Charles S. Jacobs. Es un libro que recomendaban para los jefes de proyecto y esa recomendación no estaba nada mal encaminada.

El libro trata de cómo los avances en neurologia y los escaneres de actividad cerebral pueden dar explicaciones a cómo funciona el mundo dentro de las empresas. Todos nos guiamos por estímulos externos que intepretamos internamente según nuestro estado de animo o historias anteriores que hayamos pasado. Lo que puede parecer un regalo para unos, para otros puede parecer una patada en el culo. Además no se queda sólo diciendo lo que no funciona sino que acaba cada capitulo dando un recetario de cómo se debería hacer las cosas para usar este conocimiento a nuestro favor.

Un hallazgo muy importante es que el feedback, tanto positivo o negativo no funciona. El dar una recompensa por un buen trabajo o una critica casi nunca dan el resultado esperado. En lugar de esto recomienda hacer que sea la propia persona la que tenga datos objetivos suficientes para saber si lo está haciendo bien o mal. Esto coincide con lo que promulga la metodologia agil y el scrum en concreto. Dejar que el equipo sea autogestionado y darle toda la información necesaria para ello.

La organizacion también es un punto importante del que hace mención. Dice una cosa muy curiosa que es la lucha interna que existe en nosotros y nuestra vida en la empresa ya que segun los genes que tenemos de nuestros antepasados los hominidos, luchamos individualmente por llegar a ser el macho alfa (el jefe supremo), sin embargo, necesitamos trabajar en grupos para conseguir objetivos mayores que los que puede conseguir uno mismo. Recomienda el organizarse en pequeños grupos “autonomos” para que se pueda combinar la fuerza de ambas fuerzas. Coincide con cómo funciona el scrum, organizando en grupos de 7 personas más o menos.

Según el autor, el tipo de lider que hace falta para obtener el mejor resultado no es uno que ordene sino uno que pregunte. Una pregunta concreta puede mover a una persona con mucha mas motivacion y resultado que cualquier orden. Coincide con el scrum con el hecho de que cada día se hacen las preguntas del daily scrum (qué has hecho, qué vas a hacer y qué necesitas para hacer tu trabajo).

En fin. Es un libro que ha superado mis espectativas y contiene un conocimiento que no hay que dejar escapar