sábado, 14 de enero de 2012

Herramientas para gestión ágil de proyectos de desarrollo de software

Primero que nada es importante destacar que este post está en construcción. En este post incluyo mi lista de herramientas de referencia en el ámbito de gestión ágil de proyectos de desarrollo de software. No se trata de un post desinteresado puesto que mi propósito es comparar nuestra herramienta TUNE-UP Software Process con otras existentes en el mercado. En la actualidad sin mucho esfuerzo de búsqueda pueden encontrarse varias decenas de herramientas en dicho ámbito. Sin embargo, para pocas de ellas vale realmente la pena dedicar tiempo en evaluarlas.
  
Antes de comentar respecto de las herramientas y dar algunas ideas acerca de criterios para su selección, no se puede pasar por alto el primer pilar del agilismo "Individuals and interactions over processes and tools". La clave aquí está en la interpretación más o menos radical que se haga de "over". Sin entrar en cuestiones o discusiones que no aportan, supongo que podríamos estar de acuerdo en que las herramientas como medio para conseguir un fin, tendrán mayor protagonismo en la medida que el proceso (metodología) seguido por el equipo sea más sofisticado y/o exigente. Respecto de las herramientas específicas asociadas a actividades concretas (tales como: requisitos, programación, control de versiones, pruebas, despligue, etc.) debería ser bastante clara y natural dicha tendencia, la cual estaría idealmente alineada con las necesidades del equipo (aunque no es raro que, como en otros ámbitos se adquieran herramientas dejando de utilizar gran parte de su funcionalidad :-) ). Cuando hablamos de herramientas de apoyo al proceso (apoyo a la metodología o apoyo la gestión del proyecto) la decisión o alineamiento entre las prácticas y técnicas del equipo respecto de las funcionalidades de la herramienta no resultan tan claros. No existe una cultura generalizada de utilizar herramientas para apoyar el proceso, o de centralizar y orquestar el proceso a través de una sola herramienta. Por este motivo las heramientas ágiles para gestión de proyectos aunque parten esencialmente desde ofrecer un apoyo a la planificación y seguimiento del proyecto, para ser más atractivas y prácticas derivan rápidamente hacia integraciones con otros aspectos asociados a actividades específicas de desarrollo (tales como las mencionadas antes; requisitos, pruebas, etc.).

Cuando queremos hacer una implantación exitosa del agilismo surge la pregunta: ¿cuál es la herramienta que necesita mi equipo para gestionar de forma ágil los proyectos?. Una respuesta fiel al agilismo sería: la que sea más rentable, en el sentido que la inversión que hagas en ella se vea correspondientemente recompensada en productividad y calidad. Si bien esta respuesta es sensata, no nos ayuda mucho en cuanto a la decisión que queremos tomar :-).

Muchos equipos de desarrollo están (y puede que sigan) satisfechos utilizando una hoja de cálculo o un simple tablero Kanban de pared para gestionar sus versiones y el Product Backlog de sus productos. Muchos de los inconvenientes son bastante obvios (ver post asociado a esto) pero aún así estas herramientas pueden resultar satisfactorias considerando la realidad de proceso que tenga el equipo. En mi opinión gran parte del éxito de Scrum (aparte de las cuestiones técnicas más comunmente destacadas) se debe a una interpretación que mezcla dos aspectos: un cierto desprecio a la utilización de herramientas de gestión sofisticadas (exaltando herramientas más rudimentarias), y una apuesta por hacer del desarrollo de software una actividad más social y entretenida. Si bien esto es positivo especialmente para comenzar con el agilismo, puede que después, debido a la mejora continua que el mismo agilismo promueve, probablemente dichas herramientas básicas dejarán de estar alineadas con las mejoras en las prácticas que requiera el equipo para gestión de proyectos .  

Para no extenderme más, de momento sólo destacaré las características de TUNE-UP Software Process respecto del resto de herramientas.  

Características únicas o superiores de TUNE-UP Software Process respecto del resto:
  • Esta primera característica no es técnica pero me gusta mencionarla :-). TUNE-UP nació y se ha nutrido desde tres vertientes: la docencia, la investigación y la aplicación industrial. Habla español (aunque su interfaz está en inglés :-) ), made in Valencia-España.
  • TUNE-UP no es sólo una herramienta pues conlleva una metodología de trabajo. Las opciones configurables se centran en lo extrictamente necesario para abordar la diversidad del contexto de un producto, el resto de funcionalidad está ya configurada a una forma de trabajo. Así, el equipo se concentra en la implantación de la metodología y de la herramienta, sin desgastarse en la definición de una metodología propia ni en la configuración de una herramienta que la apoye. Las opciones configurables de TUNE-UP le permiten al equipo evolucionar fácilmente desde un enfoque tradicional hacia uno más ágil, llegando si se desea, por ejemplo, a una implantación 100 % Scrum.     
  • La coordinación del trabajo se orquesta mediante workflows flexibles y configurables (con "verdaderos worflows", con roles, actividades y operadores de secuencia, selección y paralelo) que permiten el establecimiento de actividades y roles desde el estilo más puro de Scrum hasta el más tradicional, lo cual facilita en gran medida las transiciones desde enfoques tradicionales hacia otros más ágiles.
  • Enfoque TDRE (Test-Driven Requirements Engineering) para la gestión de requisitos integrada en el desarrollo del producto. Se trata de una gestión de requisitos basada en pruebas de aceptación (PAs). Todo el proceso de desarrollo está dirigido por las PAs, éstas se definen, se implementa el código para satisfacerlas y finalmente se aplican para comprobar que se satisfacen. Las PAs que constituyen la especificación de cada cambio en el producto.
  • Se ofrece una completa y sencilla gestión de tiempos. En el nivel básico sólo se registra el esfuerzo restante para finalizar una actividad. En el nivel más completo se registra inicialmente el esfuerzo estimado y el sistema apoya semi-automáticamente a registrar el esfuerzo invertido. Con esta información se elabora automáticamente un dashboard que presenta el estado de la versión. Si el producto no lo requiere puede deshabilitarse la gestión de tiempos para el producto.
  • Planificador Personal. Es el espacio donde el usuario inicia su trabajo, en él puede visualizar el resumen de toda la información que le es relevante como miembro en todos los proyectos en los cuales participa. Se incluyen actividades no terminadas, mensajes por contestar, por leer o esperando respuesta, alertas y notificaciones. Además se ofrecen múltiples facilidades para acceder seleccionar, ordenar o filtrar los datos mostrados, así como diversas formas de acceder al detalle de un ítem de trabajo específico.   
  • Gestión integral del Product Backlog y de los ítems en una versión. Se ofrecen facilidades para ordenar, seleccionar y filtrar todas la información necesaria para gestionar el trabajo pendiente, incluyendo además: renumeración de ítems del Product Backlog, movimiento de ítems hacia una versión o entre versiones, gestión de relaciones entre ítems, asignación de responsables, estimación de esfuerzo asociado a actividades, impacto de ítems en partes del producto, ayudas para el balanceo de carga entre miembros del equipo, etc.
  • Comunicación integrada en el contexto de los ítems de trabajo. Con esto se consigue prescindir en gran medida de la comunicación por email. Toda la comunicación escrita mantenida entre los colaboradores y asociada a un ítem de trabajo está incluida en él.
  • Configuraciones asociadas al producto. Cada producto tiene su(s) equipo(s), sus roles, sus workflows, niveles de testeo, nivel de gestión de tiempos, etc., aunque dichos elementos pueden compartirse entre productos.
  • Gestión de documentos a nivel de producto, de apartados del producto y de ítems de trabajo. La documentación se gestiona con Subversion, permitiendo mantener versiones de los documentos y un mecanismo de check-in/check-out para trabajar colaborativamente con ellos.
  • TUNE-UP es una herramienta gratuita. Aunque a futuro pudiéramos tener una versión de pago por licencia y que ofrezca características adicionales a las actuales, mantendremos una versión gratuita con la funcionalidad actual completa y sin ninguna limitación ni de tiempo, ni de usuarios, etc. Nuestro modelo de negocio se basa en ofrecer servicios de implantación, consultoría y soporte (ejemplo de plan de implantación que incluye formación y consultoría in situ). En caso de prescindir de nuestros servicios sólo requerimos poder referenciar a la empresa como usuaria de la herramienta.  

Mi lista de herramientas, ordenada por nombre, es la siguiente. 


























Patricio Letelier

martes, 3 de enero de 2012

Roles de Scrum - Parte II: Una estrategia para su implantación


Esta figura representa una posible estrategia de implantación de roles Scrum. En ella se intenta buscar el equivalente de un rol actual (con las respectivas personas que lo desempeñan) con respecto de los roles de Scrum. Aunque esta estrategia podría parecer razonable, en la práctica no suele ser factible ni coherente. Se estaría tratando de asimilar roles tradicionales con roles de Scrum. Un rol es simplemente un contenedor de ciertas responsabilidades (que conllevan unas correspondientes habilidades). Los roles tradicionales no son equivalentes a los roles Scrum en cuanto a responsabilidades y habilidades deseables para quién los desempeña.

Los roles de Scrum constituyen una excelente referencia como un ideal de roles (y correspondientemente de personas que los desempeñan), lo que querríamos tener en cualquier proyecto. Sin embargo, son de muy difícil aplicación, al menos a corto plazo para un equipo que trabaja actualmente con una metodología tradicional. A continuación se presenta un resumen de la Parte I de este post, insistiendo en el desafío que conlleva la definición de cada rol:
  • Product Owner. Una persona que representa a todos los stakeholders, que lidera el desarrollo del producto, activo impulsor de una visión del producto alineada con los objetivos del negocio, que interactúa eficazmente tanto con los stakeholders como con el equipo de desarrollo, capaz de definir y organizar el trabajo pendiente, el Product Owner es parte del equipo (está in-situ o muy en contacto con el equipo).
  • Scrum Master. Una persona, con profundos conocimientos y experiencia en técnicas y métodos de desarrollo de software, y en particular en agilismo, formador, entrenador y consultor respecto de la metodología de trabajo, líder en la implantación de mejoras de proceso, capaz de detectar y resolver oportunamente impedimentos que afecten el curso normal del proceso sin intervenir en decisiones de negocio ni técnicas.
  • Development Team. Compuesto por miembros proactivos capaces de colaborar eficazmente, organizando en conjunto el trabajo que enfrentarán, que están preparados y dispuestos para realizar diferentes actividades, que aunque tengan cierta especialización sólo serán reconocidos como "Desarrollador".
Otro desafío importante es que en muchos casos las personas participan en el desarrollo y/o mantenimiento de varios productos, incluso desempeñando roles diferentes en cada producto. Los roles de Scrum se establecen para cada producto, si bien no se enfatiza que la dedicación de cada persona sea exclusiva para cada producto, se asume que esa sería la situación ideal.

Conscientes de las dificultades comentadas antes, nuestra recomendación es NO obsesionarse con conseguir al 100 % la implantación de los roles de Scrum. Esto no debería representar ningún problema a menos que se quiera ser "purista" en Scrum o se desee optar a alguna certificación asociada a Scrum :-). Nuestro interés es mejora de proceso, con lo cual utilizando como referencia los roles de Scrum intentaremos acercarnos a ellos, hasta el nivel que sea posible y deseable.

Nuestra estrategia privilegia una evolución hacia el agilismo (cuando no es posible hacer una revolución). En la primera implantación e inicio del camino hacia el agilismo realizamos los siguientes pasos:

PASO 1: Diagnosticar al equipo y su situación actual de roles y personas que los desempeñan (obviamente, considerando también el contexto de los productos en los cuales participa el equipo).

PASO 2: Determinar cómo se cubrirán las responsabilidades asociadas al rol Product Owner, es decir, qué tipo de cliente podemos conseguir en el producto (cada producto puede tener uno diferente). Para esto identificamos al menos tres responsabilidades involucradas, con las siguiente preguntas:
  1. ¿Quién debería decidir qué debe implementarse en el producto (decisiones respecto de la planificación)?
  2. ¿Quién debería determinar en detalle cada cambio implementado en el producto (se refiere a detallar los requisitos específicos de cada cambio)?
  3. ¿Quién debería especificar/explicar los requisitos específicos a los desarrolladores?
Si, como en la mayoría de los casos, es imposible reunir estas tres responsabilidades/perfiles en una sola persona, habrá que replantearse desde un punto de vista realista cómo cubrirlas. Por ejemplo, si los clientes son varios, cada uno con sus propios intereses (posiblemente en conflicto), no quedará más remedio que consensuar los cambios del producto (o establecer un "despotismo ilustrado" :-) ), resolver conflictos y especialmente hacer una ardua labor de "venta" de los cambios realizados en el producto para que todos los clientes puedan sentirse satisfechos. En este caso, recomendamos denominar a estos participantes como Clientes. Cuando los clientes son varios es importante tener un rol que actúe de moderador e integrador de las necesidades de los clientes de cara al equipo de desarrollo. Por la habilidad y autoridad requerida para esta actividad puede resultar ser la transición más cercana para el Jefe de Proyecto, aunque en este caso preferíamos llamarlo Product Manager, y lo ideal es que efectivamente sea un representante de la parte cliente. Por otra parte, si quien debe detallar cada cambio es un Usuario Experto, lo mejor es llamarlo así. Finalmente, si la especificación del cambio en el producto la realiza un Analista de Negocio (o simplemente Analista) interactuando con usuarios expertos, sería conveniente reconocer dicho rol. Lo anterior es sólo un ejemplo de algunas situaciones que podrían presentarse y ciertas sugerencias al respecto, no pretende reflejar todas la diversidad que se podría enfrentar.
PASO 3: Determinar cuánto puede acercarse el equipo de desarrollo al rol Development Team. Lo primero que hay que evaluar es la viabilidad de prescindir de rol (y persona asociada) Jefe de Proyecto o similar, es decir, quien dirige al equipo, organizando y supervisando el trabajo, es decir, si el equipo está preparado para ser self-organizing, o al menos en alguna medida. Además, si se quiere y puede llevar el concepto de self-organizing a fondo, habría que resolver qué reubicación se le daría al actual Jefe de Proyecto o similar. En segundo término habría que evaluar la preparación y disposición del equipo respecto de abandonar cargos específicos o agrupaciones internas por funcionalidad (analistas, programadores, testers, etc.) con la idea que cada miembro del equipo pueda llegar a realizar cualquier actividad, aunque indudablemente pueda estár más especializado en alguna de ellas. Para esto hay que conocer con detalle qué actividades se están desarrollando actualmente y decidir si todas se abordarían con el rol genérico de Desarrollador o se mantendrían algunas con roles (y responsables) específicos y fijos. Por otra parte, con el propósito que el equipo sea cross-functional habría que intentar que todas las habilidades necesarias para conseguir una versión del producto estén disponibles y cubiertas por los desarrolladores. Si bien podrían existir ciertos miembros cosultores que no estén a tiempo completo en el equipo, los desarrolladores no deberían depender de personas no incluidas en el equipo de desarrollo para poder dar por terminado el trabajo de una versión del producto. El outsourcing de ciertas actividades y/o los equipos funcionales (por ejemplo, el área o equipo de QA) son obstáculos importantes para el concepto de cross-functional, sin embargo, si el planteamiento no es "todo o nada" es posible conseguir en parte las ventajas de dicho concepto cuando no interesa prescindir del outsourcing o de los equipos funcionales. Además, por ejemplo en el caso de outsourcing, si se consigue que el personal del proveedor esté co-localizado con el equipo de desarrollo ya no existen mayores inconvenientes al respecto. Sucedería lo mismo si, por ejemplo, se consigue que personal de QA pueda tener cierta dedicación exclusiva y co-localización con el equipo de desarrollo, aunque sea por temporadas.

Consideraciones adicionales:
  • Si no se tiene una implantación exacta de un rol, tal como lo define Scrum, NO utilizamos el nombre de rol dado en Scrum y usamos un nombre alternativo, nuevo o coincidente con uno ya empleado en el equipo. 
  • Scrum Master es un rol que exige experiencia. La primera implantación se recomienda que sea liderada por un consultor externo que desempeñe el rol de Scrum Master. Éste debe ser un especialista en agilismo que trabaje en conjunto con la persona del equipo seleccionada para formarse como Scrum Master. La idea es que después de la primera implantación quede formado un Scrum Master para el equipo, el cual pueda continuar la mejora del proceso sin la necesidad del consultor externo. El Scrum Master (externo o interno) tiene mucho más protagonismo al inicio de la implantación de Scrum en un equipo. Con el tiempo el Scrum Master es menos protagonista pero mantiene su presencia en cuanto a la promoción de la mejora continua del proceso, aunque probablemente sea suficiente que un Scrum Master tenga una dedicación a tiempo partial para un equipo.
El radicalismo en cuanto a roles planteado por la Scrum Guide, aunque ideal y conveniente, no es posible llevarlo a la práctica en la mayoría de los casos, o al menos no de inmediato para un equipo que ha trabajado con un enfoque tradicional, y para productos en los cuales no es posible tener un Product Owner puristamente. Mike Cohn aporta un toque de pragmatismo al respecto en su libro "Succeding with Agile. Software Development using Scrum".

Es indudable que cada producto-cliente-equipo tiene sus propias necesidades en cuanto a configuración metodológica, las recetas generales son sólo eso, debe siempre hacerse una adaptación al contexto para sacar el máximo de beneficio y luego ir ajustándola según el desempeño que se observe y/o se desee alcanzar. En TUNE-UP, y promoviendo una estrategia evolutiva hacia el agilismo, se proporcionan mecanismos específicos para facilitar la configuración metodológica y luego facilitar su modificación hacia estrategias más puristas en cuanto a agilismo.



Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com