jueves, 15 de diciembre de 2011

Roles de Scrum - Parte I: Responsabilidades involucradas

En esta Parte I me centraré en explicar brevemente la motivación de este par de posts y presentaré la definición de los roles de Scrum. En la Parte II explicaré nuestra estrategia para implantar los roles de Scrum.

Si bien existen innumerables referencias y definiciones a los roles de Scrum poco se comenta respecto de cómo llevarlos a la práctica. Por lo visto existe una idea generalizada que basta con formación (y certificación) para conseguir gente que desempeñe eficazmente dichos roles. Además, se pasa por alto el desafío que significa migrar a las personas desde sus roles actuales. No se trata sólo de una cuestión de estrategia para convencer de las bondades del agilismo o de cómo enfrentar a quienes puedan estar en contra explícita o implícitamente de la implantación del agilismo. Conseguir que un equipo sea  self-organizing puede ser más o menos difícil, pero conseguir que un equipo sea cross-functional con miembros que no están preparados para (ni dispuestos a) abandonar sus "títulos" correspondientes a sus roles fijos, esto sí que puede ser un gran desafío.

De entre los tres roles de Scrum, el que se lleva la palma en cuanto a polémica a su alrededor es el Product Owner. Recomiendo los siguientes post para así ahorrarme el contar en detalle la problemática asociada: The Product Owner ProblemThe Mythical Product Owner role.

A continuación se presenta la definición del los roles de Scrum, extraida y traducida desde la Scrum Guide (octubre de 2011).

Product Owner (PO)
Es responsable de  gestionar el Product Backlog, lo cual incluye:

  • Expresar claramente los items del Product Backlog
  • Ordenar los items del Product Backlog para conseguir objetivos y misión del producto
  • Asegurar el valor del trabajo que realiza el Development Team
  • Asegurar que el Product Backlog es visible, transparente, y claro para todos, y mostrar en qué es lo que trabajará próximamente el Scrum Team 
  • Asegurar que el Development Team entiende los items contenidos en el Product Backlog

El PO debe hacer respetar sus decisiones en la organización y proteger al Development Team de las solicitudes o influencias de los stakeholders

Scrum Master (SM)
Es responsable de asegurar que Scrum es entendido y aplicado. El SM es un sirviente-líder para el Scrum Team.

Servicios del Scrum Master para el Product Owner
  • Encontrar técnicas para la gestión efectiva del Product Backlog
  • Ayudar a comunicar claramente la visión, objetivos e ítems del Product Backlog al Development Team
  • Enseñar al Development Team a crear ítems claros y concisos en el Product Backlog
  • Ayudar a comprender la planificación a largo plazo en un ambiente empírico
  • Ayudar a comprender y aplicar agilidad
  • Apoyar durante el sprint y las reuniones según se le requiera o sea necesario
Servicios del Scrum Master Service para el Development Team
  • Entrenar en self-organization y cross-functionality
  • Enseñar y dirigir hacia la creación de productos de alto valor
  • Eliminar los impedimentos para su avance en el trabajo
  • Apoyar durante el sprint y las reuniones cuando se le pida o sea necesario
  • Entrenar para enfrentar ambientes organizacionales en los cuales Scrum aún no ha sido completamente adoptado y entendido
Servicios del Scrum Master para la Organization
  • Liderar y entrenar la adopción de Scrum en la organización
  • Planificar implantaciones de Scrum dentro de la organización
  • Ayudar a los empleados y usuarios a comprender  e implantar Scrum y el desarrollo empírico de productos
  • Provocar cambios que aumenten la productividad del Scrum Team
  • Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización
Development Team
  • Es self-organizing. Nadie (ni siquiera el Scrum Master) le dice cómo convertir el Product Backlog en un incremento de funcionalidad potencialmente entregable
  • Es cross-functional, tiene como equipo todas las habilidades necesarias para crear un incremento del producto
  • No tiene títulos más que el de Developer, independiente del trabajo que esté realizando la persona, no hay excepciones a esta regla
  • Los miembros pueden tener habilidades y áreas de especialización pero ellas cuentan para el Development Team como un todo 
  • No contienen sub-teams dedicados a dominios particulares como testeo o análisis de negocio
  • Tiene entre 3 y 9 miembros (obviamente sin contar el PO y SM)
Si el equipo es de nueva formación, si sus miembros tienen conocimiento y experiencia en métodos ágiles o bien si tienen la habilidades y motivación para iniciarse en el agilismo, y si las condiciones de contexto cliente-producto son favorables para el agilismo, con todo ello, la opción más interesante sería implantar Scrum a fondo en el equipo. Sin embargo, dicho entorno propicio para el agilismo suele ser una excepción, con lo cual una estrategia de revolucionaria conllevaría riesgos importantes e incluso podría ser contraproducente de cara a conseguir un cambio sostenible en el proceso de desarrollo de software. Así pues, en la Parte II de este post comentaré nuestra estrategia evolutiva para implantar estos roles en un equipo que ha trabajado hasta ahora con roles y bajo un entorno de caracter más tradicional.



Patricio Letelier

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

miércoles, 14 de diciembre de 2011

Gestión "Ágil" de Requisitos

Esta es la tan recurrida imagen usada para explicar la motivación de la Ingeniería de Requisitos. Es simplemente una exageración de lo que puede ocurrir en términos de degradación de una especificación cuando es transferida y manipulada secuencialmente entre diferentes participantes en un proyecto. En el contexto del desarrollo de un producto software esto tiene mayor probabilidad de ocurrir mientras más secuencial sea el proceso de desarrollo, mientras más personas distintas intervengan en la cadena de producción y mientras menos puntos de validación se establezcan (validación se refiere a comprobar que el producto satisface las expectativas del cliente, es decir, cumple con los requisitos acordados con el cliente).

La solución de la Ingeniería de Requisitos clásica está centrada en la especificación y validación temprana del producto. Por temprana me refiero a antes de programar :-). Esta validación tiene así un gran inconveniente, el cliente no validará respecto de un producto construido sino que lo más real o cercano que tendrá serán prototipos. Esto es así porque la Ingeniería de Requisitos tradicional en general asume un proceso en cascada, en el cual las actividades de análisis o especificación de requisitos coinciden con un período del proyecto, lo cual se delata cuando se denomina "Fase" de Análisis o similar.

La situación es bastante diferente cuando el modelo de proceso es iterativo e incremental, modelo en el cual se basan todas las propuestas metodológica modernas (sean ágiles o tradicionales). Sin embargo, se suele asociar a las metodologías tradicionales con un modelo de proceso en cascada porque desafortunadamente en muchos casos se aplican de esta forma. En un proceso iterativo e incremental el trabajo de desarrollo se divide ítems los cuales se agrupan en iteraciones (sprints), cuyo resultado es un incremento del producto que incluye cambios respecto de la versión previa. La actividad de especificación de requisitos está presente en cada uno de los ítems de trabajo, y  convenientemente se podría realizar en cualquier momento antes de pasar el ítem a una iteración para ser implementado. La especificación de requisitos no se debería concentrar en un período del proyecto, es decir, no habría una "fase de Especificación de Requisitos", sino más bien la actividad Especificación de Requisitos se realiza continuamente preparando ítems antes de que se implementen en una iteración. Así pues, los ítems que se incluyen en una iteración deberían estar idealmente ya definidos (especificados sus requisitos). Pues bien estos ítems en métodos ágiles corresponden usualmente con las denominadas Historias de Usuario. Aunque la literatura respecto de Historias de Usuario está un tanto sesgada respecto de asociar una Historia de Usuario con un "Nuevo Requisito", lo cierto que en el contexto de una iteración las Historias de Usuario también pueden representar "Mejoras" o incluso "Correcciones de fallos" en requisitos ya implementados.

El reconocer dichos diferentes tipos de Historias de Usuario ("Nuevo Requisito", "Mejora" o "Corrección de fallo") nos lleva directamente a entrar en "Gestión de Requisitos". La especificación de requisitos no es estática, va evolucionando en la medida que el comportamiento del producto lo hace. Es en este punto en el cual los métodos ágiles "renuncian" a la gestión de los requisitos una vez implementados en el producto. Con esto me refiero a que una vez que una Historia de Usuario (del tipo que sea) se implementa en una iteración, simplemente se tira a la papelera su especificación, o si se guarda, es sólo por una cuestión de registro histórico. Es decir, el comportamiento asociado a un requisito implementado y posteriormente mejorado o corregido debe averiguarse yendo directamente al código y la base de datos. No me consta que en alguno de métodos ágiles más populares se proponga almacenar y gestionar las Historias de Usuario ya implementadas con el propósito de servir de especificación actual del comportamiento del producto, puesto que de ser así debería realizarse algún tipo de síntesis de todas las Historias de Usuario asociadas a un requisito, desde su origen hasta la actualidad, pasando por todas sus mejoras y correcciones (no solo tener una colección de pos-it :-) ).

El tener que acudir al código y base de datos para conocer el comportamiento actual del producto podría no ser un gran problema si todo el equipo se desenvuelve a nivel de programación, pero muchas veces esto no ocurre. Además, el mismo cliente querría saber con precisión el comportamiento del producto. Ojo que dicha precisión no suele ser ofrecida por un Manual de Usuario, porque un manual debe orientar a un usuario para sacarle provecho al producto, no es su propósito describir en detalle la lógica asociada a cada funcionalidad del producto. Sin embargo, en mi opinión el disponer de una especificación de requisitos actualizada y más abstracta que la implementación se hace más necesaria aún cuando la envergadura o complejidad del producto es significativa, cuando difícilmente un miembro del equipo es capaz de conocer toda la funcionalidad del producto ni puede fácilmente investigar en código el impacto de los cambios.

Podríais pensar que después de lo comentado voy a apostar por gestión de requisitos "clásica", pues no! :-), ya que tampoco la gestión de requisitos clásica (en mi opinión) aborda de forma satisfactoria la evolución de la especificación de requisitos. Preguntadle a quienes utilizan Casos de Uso y Matrices de Trazabilidad si consiguen de manera efectiva y eficiente (a un costo razonable) mantener actualizadas sus especificaciones de requisitos :-). Si respondieran que están satisfechos sospecharía que no utilizan un proceso iterativo e incremental, o que tienen la suerte de desarrollar software en un contexto donde no hay cambios en los requisitos durante la construcción del producto, o donde el producto no tiene mantenimiento. Dicho contexto no creo que exista, al menos para un producto que tiene usuarios aprovechándolo.

Llegados a este punto no os voy a dejar sin una propuesta de solución :-), que sea factible y coherente con los métodos ágiles. En nuestro caso, desde que comenzamos a experimentar y aplicar métodos ágiles nos dimos cuenta del potencial que tenían las Pruebas de Aceptación (PAs) como especificación de requisitos, XP ya proponía derivar PAs para cada Historia de Usuario y utilizarlas como criterio de éxito de su implementación. En realidad la idea ya existía y es en sí el concepto de PA de toda la vida :-). Después de ver cómo en la medida que queríamos ser precisos en la descripción de una Historia de Usuario en su texto comenzaba a incluirse la lógica que debería derivarse posteriormente en términos de PAs. Así, resultó evidente que en lugar de hacer descripciones "novelescas" para Historias de Usuario era mejor escribir ese detalle directamente como PAs. De esta forma, para cada ítem de trabajo en una iteración, sea del tipo que sea (nuevo requisito, mejora o corrección), establecemos una descripción muy breve (y opcional), hacemos bocetos de interfaz cuando corresponde y básicamente nos centramos en definir PAs (incluso a veces, y puntualmente, utilizamos modelos). Con esta estrategia estamos "matando dos pájaros de un tiro", conseguimos un adecuado nivel de precisión en la definición de la Historia de Usuario y evitamos que posteriormente se tenga que hacer una interpretación adicional para extraer las PAs para poder realizar dichas pruebas. Pero esto solo es una parte, pues además teníamos que facilitar la gestión de los requisitos ante los cambios. En nuestro enfoque donde los requisitos están basados en PAs, para cada producto se establece una  estructura de grafo cuyos nodos representan requisitos, siendo cada uno de ellos un contenedor de PAs que definen el comportamiento del requisito. Así pues la gestión de requisitos se integra en el desarrollo iterativo e incremental de forma natural de la siguiente forma: cada ítem (Historia de Usuario) de una iteración se define como un cambio en la estructura de requisitos, con lo cual cada ítem puede implicar añadir, eliminar o modificar nodos, y correspondientemente añadir, modificar o eliminar PAs en dichos nodos. A nuestro enfoque lo denominados Test-Driven Requirement Engineering (TDRE) y está descrito en detalle en un artículo que publicamos en las JISBD en el 2010. El resto de la historia y los detalles corresponden a cómo hemos hecho realidad esta propuesta ofreciendo un soporte para ella en nuestra herramienta TUNE-UP Process. En el siguiente enlace puedes ver algunos ejemplos de pruebas de aceptación gestionadas en el contexto de un producto software como esencia de la especificación de requisitos.

En resumen, en mi opinión la única forma viable de gestionar los requisitos en un producto que está en continuo cambio (por estarse desarrollando iterativamente o por estar en mantenimiento) es que dicha gestión de requisitos esté totalmente integrada en la gestión del producto (en su planificación y desarrollo iterativo e incremental). Además, identificar y definir progresivamente las PAs de un cambio como parte esencial de la correspondiente especificación de requisitos resulta más rentable que invertir esfuerzo en otras formas de especificación detallada, pues de partida nos ahorra el esfuerzo de derivar PAs desde esas otras especificaciones.

Lectura recomendada: un post relacionado con este ¿Cuál y cuánta documentación/especificación es suficiente?.


Patricio Letelier

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




sábado, 10 de diciembre de 2011

Estimación en un proyecto ágil, Parte I: Una estrategia pragmática

Esta figura representa lo que se denomina el "Cono de la Incertidumbre" e ilustra cómo la variabilidad en las estimaciones de esfuerzo se va reduciendo en la medida que nos adentramos en la implementación.

Este post no pretende ser un tratado de la estimación en proyectos de desarrollo de software, sino que sólo me centraré en las técnicas más populares y que parecen estar más en sintonía con los métodos ágiles. Para tener una visión global de estimaciones en proyectos de software recomiendo el libro Software Estimation de Steve McConnell y en el caso específico de métodos ágiles mi sugerencia es el libro Agile Estimating and Planning de Mike Cohn. Desafortunadamente, en la práctica aún quedan cuestiones por resolver y eso es precisamente lo que me ma motivado escribir este post.

Estimar el esfuerzo asociado cada ítem de trabajo antes de abordarlo es en sí un esfuerzo y requiere disciplina, todo lo cual debería ser rentabilizado. A continuación se indican algunos beneficios que podría ofrecer la estimación de ítems.
    • Prever decisiones, alternativas y/o desafíos asociados a dicho trabajo
    • Establecer un plan coherente en cuanto a equilibrar esfuerzo requerido versus capacidad del equipo para abordarlo en un determinado tiempo.
    • Tener un factor adicional para considerar al momento de seleccionar trabajo para abordar. Por ejemplo, realizar cuanto antes trabajo que requiera muy poco esfuerzo, o buscar el momento adecuado para llegar a cabo un trabajo que requiera mucho esfuerzo.   
    • Realizar el seguimiento del trabajo restante, contrastando el progreso del trabajo respecto de la estimación, o simplemente descontando el esfuerzo estimado de un ítem una vez éste se haya terminado.
    La estimación del esfuerzo en métodos ágiles presenta aspectos en los cuales no existe un total consenso. El equipo de trabajo debería, para CADA uno de los producto productos o servicios de los cuales está encargado, tomar una decisión respecto de los siguientes aspectos:
    1. ¿Se estimará?. ¿Es de utilidad realizar estimaciones en el ámbito de trabajo del producto o servicio?. En caso de NO ser necesario estimar, ya no hay que tomar ninguna de las siguientes decisiones :-).El contexto ideal para el agilismo es aquel donde el equipo de desarrollo tiene una estrecha colaboración con el cliente, en el cual, si existen cambios en los requisitos del producto, el cliente entiende y acepta probables modificaciones del alcance inicialmente acordado. Pues en este contexto ideal, las ventajas de estimar se diluyen puesto que si bien existen entregas frecuentes, ellas pueden modificarse sobre la marcha en cuanto a su alcance, es decir, el éxito está asegurado puesto que, acercándose a una entrega el equipo puede acordar con el cliente quitar alcance sin que esto signifique necesariamente un fracaso en cuanto a sus expectativas. El plan se transforma en una hoja de ruta sin constituir un compromiso cerrado. Por otra parte, si no se trabaja con sprints o entregas si no que el trabajo se atiende según va llegando (priorizándolo respecto del trabajo pendiente), tal como se propone en el método Kanban, la necesidad de estimar se hace menos necesaria.
    2. Debe seleccionarse la unidad de medida para el esfuerzo, las más usadas son Tallas (S,M,L,XL), Puntos, y Horas Ideales (horas de trabajo sin interrupción). En cada cada, la elección conlleva que la capacidad del equipo deberá establecerse usando la misma unidad. En ese mismo orden, estimar con Tallas es lo más sencillo y rápido, en el otro extremo una estimación en Horas Ideales exige una reflexión más detenida respecto de qué trabajo debe realizarse al abordar el ítem. En cuanto al seguimiento, usar Tallas ofrece muy poco respecto a conocer cuánto es el trabajo restante en términos de suma de esfuerzo. El el caso de los Puntos si bien pueden sumarse para establecer, por ejemplo, que quedan X puntos de trabajo restante, se trata de una medida discreta, es decir, los puntos de un ítem no se restan hasta que el ítem está terminado, no tiene sentido hacer cálculos de cuántos puntos le quedan a un ítem una vez empezado. Las Horas Ideales sí que permiten dicha actualización de tiempo restante para terminar un ítem ya empezado. Otro elemento a considerar es la reconocida presión que ejerce sobre el equipo el tener que estimar en Horas Ideales y las típicas malas interpretaciones en cuanto a que no se corresponden con el tiempo cronológico ni contractual. Estimar en Tallas o Puntos evita dicha presión. Finalmente, 
    3. En caso que la unidad elegida para estimar sea Puntos u Horas Ideales, si además interesa llevar un seguimiento diario del esfuerzo restante, debe decidirse si dicho esfuerzo restante se irá registrando directamente (tal como se sugiere en Scrum), o si el esfuerzo restante se calculará en base a la diferencia entre la estimación y el esfuerzo invertido. En el primer caso, cada día el equipo debe actualizar el esfuerzo restante de todas los ítem que están empezados y no terminados. En el segundo caso, cada ítem tiene estimación y a esta se le resta el esfuerzo invertido para obtener el esfuerzo restante. En este último caso además hay que detectar cuándo la estimación inicial ya no es válida y re-estimar. El esfuerzo restante se presentaría en una Gráfica Burndown
    4. Debe decidirse si la estimación se llevará sólo a nivel de los cambios acordados con el cliente (p.e. Historias de Usuario) o también se computará a nivel de tareas de programación (unidades en las cuales el equipo de desarrollo puede descomponer dichos cambios, usualmente asociado a trabajo en partes de la arquitectura interna del producto). En términos generales sugiero NO dividir los ítems en unidades o tareas, normalmente tampoco es necesario puesto que si los ítems son pequeños pierde sentido el dividirlos aún más. Podría ser interesante usar tareas cuando un ítem sea grande (una Épica) y se haya decidido mantenerlo así, previendo que varias personas trabajarán en él en el momento de implementarlo. Trabajar con dos niveles de estimación resulta demasiado complicado en cuanto a su gestión, especialmente cuando el número de ítems y/o tareas es alto.
    5. Debe decidirse si se la estimación se hace para el ítem de trabajo como un todo (p.e para la Historia de Usuario) o para sus actividades (p.e. Programar, Testear, etc.). Siendo minimalista, cada ítem deberá ser Definido, Programado y Testeado (me refiero a pruebas de aceptación), o visto de otra forma, deberá ser Preparado (mientras está en el Backlog) e Implementado (cuando está en el sprint). Las actividades específicas que se realicen sobre el ítem dependerán del producto o servicio y del equipo, sin embargo, desde la perspectiva de la estimación, nos basta con disponer de estimación de las actividades que se realizarán durante el sprint (incluso de sólo algunas de ellas). Además, es interesante al menos hacer una separación de la estimación de Programación y de Testeo (pruebas de aceptación) pues lógicamente deberían hacerla diferentes miembros del equipo. 
    Una cuestión que parece estar consensuada es que en el contexto ágil la estimación se hace mediante "el juicio del experto", es decir, la decide el desarrollador, de forma individual o consensuada con todo el equipo de desarrollo (p.e. usando la técnica Planning Póker cuando la unidad utilizada es Puntos).

    Si bien la literatura asociada a estimación es bastante extensa, como es de esperar, no existen recetas generales. Para aquellos productos o servicios en los cuales sí que nos interesa gestionar el esfuerzo hemos tenido que abordar desafíos para que dicha gestión sea rentabilizada y se integre de forma apropiada dentro del método de trabajo del equipo. En este sentido en nuestra herramienta Tune-up hemos incluido toda la funcionalidad que hemos necesitado, permitiendo que cada producto tenga su propia estrategia de gestión del esfuerzo.

    Este post continua en "Estimación en un proyecto ágil: Parte II, Algunas diferencias respecto de estimación tradicional".

    Patricio Letelier

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

    jueves, 1 de diciembre de 2011

    Más práctica y menos teoría

    Me decidí a escribir este post después de leer el artículo "Más práctica y menos teoría" aparecido en el País Semanal del 23/10/2011, escrito por Jenny Moix (con la ilustración adjunta de Alberto Vásquez). Lo tenéis en http://bit.ly/nHWLlG.

    Hace bastante tiempo me había dado cuenta del hecho que cada vez estaba leyendo más y quedándome con menos. Me explico con un ejemplo, me pongo a leer 4 capítulos de un libro, unas 30 páginas y voy apuntándome notas, al final de mi lectura no he escrito más de 10 frases. Más aún, al recorrer dichas frases ya ni siquiera me parecen de valor y termino tirando el papel. Sin embargo, la lectura me pareció interesante, ... aparente contradicción ¿o no?. La misma situación me ocurre en la mayoría de las charlas a las que asisto, apunto un par de frases o ni siquiera eso. Obviamente lo que no voy a pensar es que ya lo sé todo, probablemente lo que tendría que hacer es acceder a información más especializada. De todas formas tanto en la lectura como en la asistencia a charlas el beneficio no sólo está en el contenido sino en el estado de reflexión al cual te somete la situación y por supuesto en el caso de las charlas, el poder contactar con gente que comparte intereses, al menos eso siempre es un buen aliciente.

    ¿A qué viene esto?, ¿qué relación tiene con agilismo?. Pues simplemente que dichos libros y dichas charlas en mi caso son sobre agilismo, lo cual ocupa una parte importante de mi dedicación actual :-). Si a lo comentado le sumamos la enorme cantidad de información ofrecida en internet, te obliga a ser más selectivo, pero el problema es que todo a priori parece interesante.

    No se trata de que no deba existir literatura y charlas introductorias, son imprescindibles para quienes comienzan con el agilismo. Aquí los gurús tienen un rol protagonista en cuanto a saber explicar fortalezas y debilidades del enfoque, dando la motivación inicial para convencernos que vale la pena probarlo. ¿Pero cuál sería la literatura o charlas avanzadas?. Podrían ser las historias de éxito, pero resulta que en este caso son "triunfalismo puro", tal como en las entrevistas que hacen a los actores durante la promoción de su película, frases del estilo "trabajar juntos ha sido un gran desafío, hemos dado lo mejor y todos mis compañeros son geniales". Temas asociados a dinámica de grupo, reuniones, liderazgo, coaching, etc., es prácticamente literatura de autoayuda, sin ánimo de subvalorarla, puesto que en este caso sí que a priori soy consciente que no encontraré respuestas concretas. La última versión de la Scrum Guide (octubre de 2011) se ha quedado en sólo 16 páginas y dando el mensaje "en otros sitios se explicará la estrategia, aquí sólo están las reglas".

    A continuación explicaré por qué pienso que en el terreno de las herramientas y su aplicación me parece que deberían estar las respuestas más concretas acerca de cómo deben hacerse en detalle la implantación del agilismo. Probablemente con la frase anterior os saltaría la alarma: violación del primer principio del agilismo "Las personas y su interacción por sobre los procesos y las herramientas". Bueno, al margen de la interpretación más o menos radical que se le quiera dar a este principio, al menos estaremos de acuerdo que las herramientas son, en general, útiles y necesarias. Por supuesto que se deben primar las personas y su interacción, particularmente lo que esto conlleva en términos de: disciplina de comunicación, de reuniones, proactividad de los miembros, equipo auto-organizado, etc., pero esto puede y debería acompañarse con un adecuado apoyo de proceso y herramientas. Esto se hace aún más importante cuando las condiciones ideales de aplicación de una metodología ágil como Scrum no pueden conseguirse en su totalidad o profundidad, por ejemplo si el equipo está distribuido, si el trabajo sobre el Poduct Backlog no lo realiza el cliente sino que debe asumirlo el equipo de desarrollo, si los miembros del equipo no trabajan en un solo producto, si el volumen de ítems en una iteración es alto, etc.

    Comencé en el año 2000 a interesarme por el agilismo, en esa época lo más popular era XP. Lo introduje en mi docencia e investigación. En el 2004 comencé a aplicarlo en proyectos industriales y en paralelo fuimos desarrollando una herramienta de apoyo. Estos últimos años nos hemos volcado a experimentar y aplicar Scrum en docencia y en proyectos reales, así como en ofrecer un soporte específico en nuestra herramienta. Las herramientas de apoyo a procesos (no sólo a actividades concretas como puede ser un entorno de programación o de pruebas) no son fáciles de implantar. O bien deben ser muy configurables para que en cada contexto se usen de forma muy diversa o bien deberían imponer una forma específica (y conveniente) de trabajo a la cual debes adaptarte. En nuestro caso hemos optado por esta última estrategia, hemos desarrollado una herramienta que conlleva una metodología de trabajo y que deja sólo unos pocos aspectos claves configurables (workflows y niveles de gestión de tiempo). Esto nos llevó a definir en mucho detalle no sólo la herramienta sino la forma de trabajo asociada a la herramienta.

    Cuando tienes una herramienta muy configurable como por ejemplo JIRA, tienes un "arma de doble filo" puedes hacer con ella lo que te parezca pero queda en tus manos la metodología de trabajo, el equipo debe establecer cómo se integrará la herramienta en su trabajo. Así pues, cuando no tienes un método de trabajo definido y no tienes o no te das la oportunidad para definirlo podrías quedarte sólo en usar JIRA como una hoja de cálculo de propósito específico :-). Si por el contrario tienes definido o defines tu método de trabajo especificarás workflows, consultas, dashboards, etc., todo muy adaptado a tu método de trabajo. Pero en este último caso ¿cuál es la configuración que deberías hacer?. Aquí volvemos al punto de la literatura y charlas sobre agilismo. En general, en ellas encontrarás muy pocas pistas respecto de cómo debes configurar tu herramienta (o grupo de herramientas) para dar soporte a tu método de trabajo. Por otra parte, la mayoría de las herramientas ha optado por ser muy configurables, quedando claro que la definición del proceso está en tus manos.

    Me reafirmo en que lo importante no es la herramienta ni el proceso, sino qué se consigue con ellos, el objetivo final es aportar el máximo de valor al cliente. Sin embargo, y asociado a mi reflexión acerca de la teoría y la práctica en el agilismo, en nuestro caso ha sido el desarrollo y la mejora de una herramienta, y en su utilización en la práctica la que nos ha obligado a enfrentar muchos desafíos específicos que no suelen ser tratados en la teoría.

    Un ejemplo: Desde que me inicié en el agilismo con XP, me sedujo su énfasis en las pruebas de aceptación, éstas deberían especificarse al mismo tiempo que se define la Historia de Usuario pues son su criterio de finalización. Comenzamos aplicando esta idea en docencia trabajando con fichas de papel para las Historias de Usuario y escribiendo en su parte posterior las pruebas de aceptación, pero inmediatamente detectamos las limitaciones que presentaba este soporte. Luego utilizamos intensivamente pruebas de aceptación en la especificación de requisitos para productos industriales, registrándolas en documentos asociados a los cambios (que ya gestionábamos con una herramienta). Vimos que estábamos siendo ineficientes puesto que toda la especificación de comportamiento que representaban las pruebas se quedaba en la especificación del cambio, y era difícil aprovechar dichas especificaciones en futuros cambios. Debido a esto, implementamos un soporte para poder gestionar eficazmente las pruebas de aceptación. A día de hoy, y después de sucesivas mejoras, tenemos un soporte muy completo para gestionar pruebas de aceptación como elemento principal de la especificación de requisitos, además, todo el proceso gira en torno a las pruebas de acptación. Uno de los productos con los que trabajamos tiene ya alrededor de cerca de 10.000 pruebas de aceptación. En este aspecto seguimos haciendo mejoras tanto al proceso como a la herramienta. La idea estaba planteada desde un principio, lo difícil ha sido desarrollarla y llevarla a la práctica. En este camino de mejora continua mucho de este conocimiento ha quedado en la herramienta.

    Espero que llegado a este punto de la lectura no te pase lo mismo que a mí, y que al menos habrás apuntado una idea interesante :-). Quédate al menos con el enlace de nuestra metodología y herramienta TUNE-UP www.tuneupprocess.com, donde sí que encontrarás respuestas específicas para todos los detalles que conlleva una implantación del agilismo :-).



    Patricio Letelier

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