¿Qué tienes en tu Backlog (y en tus Sprints)?

Una adecuada gestión del Backlog es crucial para el éxito del trabajo realizado por el equipo. La responsabilidad de dicha gestión es del Product Owner (PO), quien es la última palabra en cuanto a su contenido, al Orden de ejecución y a la definición de cada "pieza de trabajo". En "Gestión eficaz del Backlog" se indican 14 criterios que en conjunto se podrían utilizar para determinar dicho Orden de ejecución. Normalmente el PO se apoya en el equipo de desarrollo para gestionar el Backlog y para decidir el contenido de cada Sprint pero no deja de ser su responsabilidad. Pero hay un aspecto que muchas veces se pasa por alto o sin cuestionarlo demasiado: ¿Qué tipo de trabajo debería contener un Backlog o Sprint?. La respuesta inmediata podría ser: Historias de Usuario (HU). Scrum denomina "ítems" a los elementos del Backlog y de los Sprints, yo prefiero llamarlas UT (Unidades de trabajo). Pero más allá del nombre lo importante es a qué representa una UT. Es en esto en lo que me centraré en este post.

En el método ágil Extreme Programming (XP) se propone tener un Backlog con Historias de Usuario que a su vez se dividen en Tareas de programación. Es decir, se proponía tener dos niveles de gestión, uno al nivel de HU para la planificación y seguimiento visible para el cliente y otro al nivel de las tareas técnicas para los desarrolladores, llevando en cuenta que el término de todas las tareas asociadas a una HU conlleva el término de la HU. 

En la Guía de Scrum solo se habla de "ítems". Sin embargo, se indica lo siguiente: "For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.". Es decir, puede haber una descomposición de los ítems en otros más pequeños pero no se indica explícitamente si se trata de tareas técnicas o si deben ser ítems "legibles" por el PO. Sin embargo, Scrum enfatiza que el PO es responsable de la gestión del Backlog con lo cual dichos ítems deberían ser definidos desde un punto de vista del cliente o usuario (no como tareas técnicas).

En cualquier caso, si trabajamos con dos niveles de descomposición del trabajo (nivel de UT y nivel de las tareas técnicas asociadas a cada UT) podríamos tener la mala tentación de, por ejemplo, preocuparnos de que la estimación de una UT que representa un requisito, se corresponda con las estimaciones de las tareas técnicas en las cuales de descompone. Digo "mala" porque estas estimaciones y registros de tiempo invertido en dos niveles probablemente nos complicarán la gestión del trabajo sin ganar significativamente mayor precisión :-).

Vamos ahora al grano en cuanto al contenido del Backlog y de un Sprint. Podemos identificar al menos cinco tipos de trabajo en el contexto de un equipo encargado al desarrollo y/o mantenimiento de un producto:

• Tipo 1. Cambios en el comportamiento del producto: implementación de Nuevos requisitos, Mejoras en requisitos ya implementados o Correcciones de fallo.
• Tipo 2. Tareas técnicas asociadas al proceso de cada cambio en el comportamiento del producto. Por ejemplo, Especificar requisitos, Diseñar, Programar, Probar, etc., actividades realizadas para cada uno de dichos cambios.
• Tipo 3. Tareas técnicas asociadas a la arquitectura del producto. Por ejemplo, cambios puntuales en el front-end, back-end, o en el esquema de la BD. 
• Tipo 4. Tareas técnicas que no cambian el comportamiento del producto pero están en su contexto de trabajo. Por ejemplo, refactorizaciones del código (aquellas que no se asuman dentro de las implementaciones de cambios de comportamiento en el producto), cambios en la infraestructura hardware o software de los entornos de desarrollo o producción, tareas de automatización de procesos, tareas de automatización de pruebas, migraciones de datos, etc.
• Tipo 5. Otras tareas: investigación en nuevas tecnologías, formación del equipo, etc.

Claramente, el trabajo de tipo 1 lo podría solicitar y gestionar el PO (en su perspectiva de cliente del producto), es decir, este tipo de UT debe estar en el Backlog o en Sprint.

El trabajo de tipo 2 es la dimensión ortogonal a la dimensión de los contenedores (Backlog y Sprint), es decir, una UT al mismo tiempo que está en un contenedor estará en una cierta actividad de su proceso (en cierta columna de un tablero kanban). Ver "Organización ágil del trabajo: Dos dimensiones" Con lo cual, estas actividades NO tiene sentido incluirlas como UT en el Backlog o en Sprint, pues son las actividades por las cuales pasará una UT en su procesamiento y que son parte de un workflow, plasmado en un tablero kanban.

El trabajo de tipo 3 es una descomposición técnica de lo que conlleva la implementación del trabajo de tipo 1. Estas serían las tareas de programación a las que se refiere XP. Pero este trabajo de tipo 3 no lo  debería gestionar el PO, son los desarrolladores quienes al momento de abordar una UT de tipo 1 decidirán la conveniencia de una descomposición desde una perspectiva estrictamente técnica. Estas tareas deberían estar "embebidas" en las UT de tipo 1 para que no compliquen la gestión desde la perspectiva del PO, pero que al mismo tiempo puedan gestionarse por los desarrolladores. Por ejemplo, una UT llamada "Facturas pendientes de pago", que muestra en un formulario la lista de facturas pendientes de pago, puede que cuando llegue a su actividad "Programar" sea descompuesta en tareas en paralelo al estilo: "implementar front-end", "implementar back-end", etc. Incluso en el caso de tener desarrolladores full stack puede que estas tareas técnicas las pueda realizar todas un mismo desarrollador, con lo cual puede que ya no sea tan interesante descomponer el trabajo técnico de programación.

La siguiente figura ilustra el trabajo el trabajo de tipo 1 (en la vista del PO) y tipo 3 (en la vista de los desarrolladores). 

Las tareas de tipo 4 y tipo 5 no son gestionables por el PO pero es importante que se vean explícitamente como parte del trabajo del equipo pues al momento de realizarlas le restarán Capacidad, lo cual requerirá un acuerdo con el PO al momento de que se realicen. Bastaría con tener un filtrado sencillo de estas UT para que las pueda visualizar el PO o el equipo cuando estimen conveniente.

He visto con sorpresa en algunos equipos (y en repetidas ocasiones) que trabajan con un Backlog o Sprints donde en su gran mayoría solo hay UT del tipo 3. Los desarrolladores trabajan "cómodamente" con objetivos técnicos, y usualmente muy desconectados del resultado final (el cambio de comportamiento en el producto, el incremento que se espera y el valor aportado). Además, dicho resultado se ve postergado hasta integrar varias UT de tareas técnicas, que en el peor de los casos podría ocurrir después de varios Sprints. Scrum establece que el resultado de un Sprint debe ser un incremento del producto que potencialmente podría pasar a producción, es decir, aunque puede que no esté completa la funcionalidad, lo que ya está implementado debe ser operativo. Cuando esto no se cumple se está perdiendo una de las grandes ventajas que ofrece el trabajar con Sprints: la validación continua y frecuente del PO. Por ejemplo, si en un Sprint solo se ha conseguido implementar una parte back-end del producto el PO no puede validar nada. O si solo se ha conseguido implementar parte front-end pero no está operativa porque falta implementar e integrar con una parte back-end tampoco permitiría hacer una validación completa. Pienso que estos escenarios suelen darse en contextos donde el PO básicamente es un Jefe de Proyecto tradicional embestido de PO :-), el cual sigue repartiendo faena técnica a los desarrolladores y él lleva aparte la gestión de los compromisos con el clientes o los usuarios, probablemente en otro Backlog y Sprints :-). 

Para terminar y asociado a la anomalía antes comentada os dejo un texto extraído desde https://www.scrum.org/about

Fighting “Flaccid Scrum”

By early 2009, more organizations were using Agile processes than waterfall processes, and of those employing Agile 84% were using Scrum. However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. Martin Fowler wrote in his blog that he was encountering many instances of "Flaccid Scrum." Teams were using Scrum vocabulary but weren’t able to create a potentially shippable increment of functionality within a single Sprint.

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

 

Evaluación y mejora del desempeño en un contexto metodológico ágil

 

En este post os presento un modelo que he desarrollado para la evaluación y mejora del desempeño de equipos y de sus integrantes en el marco de una gestión ágil del trabajo. 

Contexto: llevo bastantes años refinando este modelo en dos asignaturas de Ingeniería Informática en mi universidad, donde los estudiantes trabajan en equipos usando un enfoque ágil para desarrollar un producto software. Cada semestre lo aplico en alrededor de 15-20 equipos de 4-6 integrantes, con lo cual está bastante rodado aunque siempre es mejorable. La idea es comenzar a aplicarlo también en un ámbito de empresa donde se trabaje con el enfoque ágil. Vamos al tema ... 

La evaluación y mejora del desempeño de los empleados de una empresa y de los equipos de trabajo es un asunto importante y en general me atrevo a decir que no está resuelto satisfactoriamente ni en un ámbito de gestión tradicional del trabajo ni en uno ágil. De hecho, hasta donde he podido averiguar no existen propuestas específicas para el enfoque ágil y se da la paradoja que en empresas donde se trabaja con métodos ágiles la evaluación de su personal se hace normalmente de forma "tradicional", me refiero a que no está integrada y adaptada a la dinámica de los equipos que trabajan con una metodología ágil, suelen centrarse solo en la evaluación de las personas, no incluyen la evaluación del equipo, y esto en un contexto ágil podría romper la dinámica ágil del equipo.

 

Al decir "evaluación de equipos que usan una metodología ágil" inmediatamente podrían surgir expresiones como "No es necesario hacer evaluaciones porque los equipos son autogestionados" o "Es el PO (Product Owner) el que evalúa al equipo en cuanto a su satisfacción con los resultados y el valor aportado". De forma similar, respecto de evaluaciones de integrantes del equipo podría decirse "Eso ya lo estamos comentando cuando surgen problemas". En parte estas expresiones son correctas pero en la práctica hay bastante margen de mejora respecto de cómo hacer dichas evaluaciones y cómo sacarles provecho.

El principal propósito de una evaluación de desempeño debería ser el orientar al personal hacia una mejora de su desempeño. Sin embargo, una evaluación de desempeño puede tener otros usos adicionales asociados a recompensas o penalizaciones para el equipo o sus integrantes. Con lo cual, en cuanto a la "justicia" de la evaluación, es conveniente que se formalice y sea transparente para todos los involucrados.

Es importante destacar, que a lo largo del tiempo un equipo y cualquiera de sus integrantes puede tener variaciones en su desempeño. Lo deseable es que el desempeño mejore, o si ya es satisfactorio se mantenga, y que los defectos en el desempeño se detecten y resuelvan oportunamente. Por esto, sería conveniente que la evaluación de rendimiento esté siempre abierta, es decir, que se pueda modificar en cualquier momento según las evidencias (positivas o negativas) que se vayan manifestando. Sin embargo, el análisis de las evaluaciones debería tener cierta frecuencia o podría estar alineada con hitos del trabajo (finalización de Sprint y/o de proyecto, entregas de trabajo, etc.), de manera que la detección de anomalías y puesta en marcha de acciones correctivas se haga oportunamente.

En la propuesta de roles de Scrum (accountabilities = responsabilidades, renombrado así en la última versión de la Scrum Guide) no existe la figura de "Jefe". El PO es la última palabra en lo que respecta a decisiones de negocio, el equipo autogestionado es quien decide respecto de lo técnico y el Scrum Master tiene autoridad en cuanto a la definición y aplicación de la metodología pero no es la última palabra ni en lo de negocio ni en lo técnico. Con lo cual cuando existen deficiencias en el desempeño del equipo y/o de sus integrantes, o cuando existen conflictos dentro del equipo y/o con el PO (o con el Scrum Master) se echaría en falta alguien que tuviese la autoridad para intervenir. Una opción razonable sería dejar esta tarea en manos del Scrum Master pues, aunque de forma indirecta, los problemas de rendimiento y conflictos son impedimentos para conseguir el máximo desempeño del equipo. De esta forma, el Scrum Master es quien debería también revisar periódicamente las evaluaciones y comentar posibles anomalías en la Reunión de Retrospectiva.  

¿Pero qué es el desempeño?. La respuesta no es tan obvia como parece, pues son varios los interesados o posibles evaluadores del desempeño, y cada uno tiene una perspectiva diferente. Es decir, el contenido, forma, y frecuencia (el qué, cómo y cuándo) de la evaluación podría ser diferente. 

En el marco de las responsabilidades propuestas por Scrum la siguiente imagen ilustra , se muestran las posibles evaluaciones de desempeño que podríamos establecer. 

El PO evaluaría el resultado conseguido por los desarrolladores. Podría hacerlo después de cada Sprint o cada cierto período de tiempo, y adicionalmente, si se trata de un proyecto, se podría hacer cuando termine el proyecto. Por contraparte y opcionalmente, el equipo también podría evaluar el desempeño del PO.

El resto de las evaluaciones tiene ya un espacio bien definido en Scrum; son las Reuniones de Retrospectiva, que deberían realizarse al finalizar un Sprint o si no se trabaja con Sprints, debería hacerse con una cierta regularidad.

La evaluación por parte del Scrum Master estaría orientada a detectar y resolver impedimentos, y a establecer mejoras en la metodología de trabajo del equipo. Por contraparte y opcionalmente, el equipo también podría evaluar el desempeño del Scrum Master. En cuanto a los impedimentos, el Scrum Master y el equipo tienen la oportunidad de detectarlos en las Reuniones Diarias (Daily Meeting) pero aquello que no tenga una solución sencilla o inmediata se puede trasladar a la Reunión de Retrospectiva. La evaluación hecha por el Scrum Master estaría asociada principalmente a la gestión de las prácticas ágiles aplicadas por el equipo en su trabajo, orientando respecto del refinamiento de las prácticas ya implantadas. 

Además, sería responsabilidad de Scrum Master el establecimiento de un adecuado sistema de evaluación de desempeño, ya que es parte de lo que se espera de él o ella en cuanto a ofrecer un buen servicio de apoyo para mejora de los métodos de trabajo.

La Autoevaluación y Coevaluación interna de los Desarrolladores deberían estar alineadas, es decir, tanto en contenido, forma, y frecuencia podrían coincidir, la diferencia obvia es que una evaluación representa cómo se ve una persona y la otra es cómo la ven sus compañeras/os de trabajo. Estas evaluaciones podrían actualizarse regularmente en cada Sprint o cada cierto tiempo, pero es importante que además estén disponibles para su modificación en cualquier momento para poder reflejar alguna evidencia puntual durante cualquier día de trabajo.

Resumen de esta propuesta de modelo para evaluación de desempeño:

• Es un sistema de evaluación y mejora orientado a equipos y sus integrantes, trabajando con un enfoque ágil.
• Se trata de una evaluación continua, las evaluaciones y su análisis lo pueden hacer en cualquier momento los interesados.
• Se basa en baremos específicos configurables según los intereses de los evaluadores. Esto permite enfrentar dos aspectos clave: los equipos evolucionan (Modelo Tuckman para explicar el desarrollo de los equipos), y por otra parte, las personas pueden tener diversas fortalezas (y debilidades), lo importante es que en conjunto se complementen para formar un buen equipo (Roles de Belbin). No es necesario ni conveniente forzar a que una persona destaque en todas las competencias, y por contraparte, sí que es importante verificar que todos los Roles de Belbin sean cubiertos al sumar los Roles de Belbin de los miembros del equipo.
• Incluye evaluación del equipo por el PO y el Scrum Master, opcionalmente considera la evaluación del PO y Scrum Master por parte de los miembros de equipo, e incluye autoevaluación y coevaluación entre los colaboradores en un equipo.
• Considera la posibilidad "no evidencia" en algunos aspectos de los baremos de evaluación. Es decir, puede que en un cierto momento un evaluador no tenga suficientes evidencias para valorar algún ítem del baremo.
• Aunque podría utilizarse en un nivel directivo la intención original es evaluar equipos y personas en el nivel operativo.
• No es un sistema para evaluación uniforme, no lo es respecto de los baremos de evaluación, ni tampoco lo es respecto de las propias valoraciones. Esto último se debe a que es muy difícil garantizar una total objetividad, y menos que una evaluación de equipo o entre personas de distintos equipos sea comparable.
• El propósito es detectar e intentar resolver situaciones anómalas oportunamente. Sin embargo, este sistema podría utilizarse para recompensar o penalizar a las personas pero hay que tener en cuenta la posible lo anteriormente indicado; la no uniformidad de las evaluaciones, especialmente entre distintos equipos.
• La evaluación realizada por los colaboradores es anónima, cada Desarrollador no conoce las evaluaciones que le han hecho sus compañeros, solo ve el promedio ponderado. Sin embargo, el Scrum Master sí que tiene toda la visibilidad y con ello puede moderar una parte de la Reunión de Retrospectiva donde comente con el equipos las evaluaciones individuales. 

Tenemos gran parte del modelo ya implementado en una herramienta que hemos utilizado ya los dos últimos años. A continuación, se muestran algunas de las principales funcionalidades ya cubiertas.

La siguiente imagen corresponde a la interfaz en la cual cada persona evalúa a sus colaboradores directos, que corresponden a sus compañeros en los equipos en los cuales participa. Cada uno de sus colaboradores aparece como una columna. 

El baremo de evaluación se estructura en Competencias y Dimensiones (primera columna de la imagen). Tanto las competencias como sus dimensiones son configurables, en este ejemplo se han establecido cuatro competencias y cada una de ellas con tres dimensiones. La evaluación puede hacerse por rúbricas (guías para otorgar cada valor de la escala) o como en la imagen, simplemente planteando una afirmación y ofreciendo una escala de Likert para evaluar. Las rúbricas y valores de escala de valoración también son configurables.

En la siguiente imagen se muestra la evaluación que haría un Scrum Master al equipo. A la izquierda se muestran las evaluaciones globales de cada Sprint, y seleccionando un Sprint se ve el detalle de la evaluación según el baremo establecido para ese Sprint. Como se observa, los ítems del baremo pueden tener diferentes pesos y de esas valoraciones se obtiene un promedio ponderado para cada Sprint.

Finalmente, cada integrante del equipo puede visualizar en una interfaz como la que se muestra a continuación con las evaluaciones que ha obtenido de sus colaboradores.

En la parte izquierda puede ver las evaluaciones que tiene su equipo en cada Sprint, y la evaluación promedio de sus colaboradores. En este caso, para ajustar la evaluación de la persona en un Sprint, se aplica una recompensa o penalización según la diferencia entre su evaluación ponderada de competencias y la evaluación promedio de sus colaboradores. Es decir, la valoración final contempla una recompensa por destacar positivamente o una penalización por destacar negativamente. Dado que la evaluación se mantiene abierta durante todo el proyecto, las personas que tengan un mal desempeño tienen la oportunidad de mejorar posteriormente pues la evaluación final es la que se considera para dicho ajuste.

Me atrevo a decir que en el contexto académico el modelo aquí ya ha demostrado ser eficaz. Más allá de permitir otorgar una calificación justa a los estudiantes, el modelo está permitiendo detectar tempranamente defectos en el funcionamiento de los equipos, ofreciendo orientación respecto de lo que se debe mejorar y motivando a hacerlo en los Sprints siguientes. Además, los resultados de una reciente encuesta hecha para recabar la opinión de los estudiantes respecto del método de evaluación arrojó los siguiente resultados (sobre 94 respuestas): el 87% está de acuerdo o totalmente de acuerdo en que el método de evaluación es justo, el 66% está de acuerdo o totalmente de acuerdo en que el método promueve la mejora en el rendimiento del equipo e individual (un 20% está indeciso), y el 94% está en desacuerdo o totalmente en desacuerdo en que el método creó algún conflicto en su equipo.

Por último, estamos recolectando la información del histórico de cambios en las evaluaciones, con lo cual pronto se podrá visualizar la evolución de las evaluaciones a nivel de competencias y dimensiones para cada persona.

Patricio Letelier

twitter.com/yopolt

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

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

 

Nuestro Product Owner NO cumple con sus responsabilidades ¿qué podemos hacer?

La respuesta rápida y fácil a una situación en la cual el Product Owner (PO) no acepta o no favorece la aplicación del enfoque ágil es: "no podemos aplicar el enfoque ágil". Sin embargo, esta decisión es demasiado radical, esta situación desfavorable aunque supone limitaciones, no tiene por qué implicar no aplicar nada del enfoque ágil. Para consuelo, la buena noticia es que en esta situación al menos tenemos identificado al PO :-), pues siempre será peor no tenerlo claramente identificado. La definición e importancia del PO la podéis consultar en mi post "Se busca Product Owner ...".

Para evaluar el impacto de tener un PO que no cumpla con sus responsabilidades podemos repasar las prácticas ágiles que están estrechamente asociadas al PO, analizando qué supondría que su participación no fuese la esperada, y ver hasta qué punto se pondría en riesgo la efectividad una práctica, y por ende una menor eficacia de la transformación ágil. 

Tomaré como referencia las prácticas ágiles de nuestro catálogo Agilev-Roadmap (en este enlace encontraréis la lista de prácticas y una explicación de cada una de ellas) y comentaré qué prácticas ágiles podrían verse más directamente afectadas por no contar con un PO "óptimo" según la definición de sus responsabilidades, y daré además algunas recomendaciones al respecto.

PRA01. Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente. Estrategia MVP, y PRA02. Abordar trabajo de forma incremental.

Comentemos estas dos prácticas en conjunto pues están estrechamente relacionadas. Si el PO solo ve como alternativa las opción más ambiciosa en cuanto a todas las características del producto y/o en cuanto a cada una de ellas, es muy complicado llevar a cabo un desarrollo incremental del producto. En cada incremento del producto tendremos características grandes (Épicas) que por dicha ambición dejarán poco espacio para incluir otras características. Esto es extensible al global del proyecto, es decir, será difícil poder desarrollar todas las características cumpliendo con las restricciones de plazos y costos. El equipo de desarrollo puede intentar ayudar en esta reflexión al PO para conseguir acotar el alcance del proyecto y de cada característica, sin que la solución sea insatisfactoria, pero la decisión y responsabilidad en última instancia es del PO. 

PRA03. Realizar entregas frecuentes de unidades de trabajo terminadas.

Si el PO NO acepta que se hagan entregas parciales y solo quiere poner en producción el producto una vez esté totalmente terminado se acumularán riesgos hasta ese momento. Las entregas frecuentes (parciales) permiten validar que el proyecto va en buena dirección y no se aumenta la tensión hacia el final cuando ya queda poco margen de reacción. No es solo una cuestión de validar que estamos construyendo el producto correcto para el usuario final, sino de detectar posibles inconvenientes "externos" de forma oportuna, por ejemplo: carencias de infraestructura, de formación de los usuarios, desafíos de integración con otros sistemas, problemas de migración desde sistemas actuales, etc. Todos estos elementos suelen presentar imprevistos que a veces son difíciles de prever y necesitan esa entrega parcial para ponerlos en evidencia. Una entrega parcial no tiene por qué ser un paso a producción como tal, sino que si esto no es posible o recomendable podemos acotarlo a, por ejemplo, un paso a un entorno de preproducción donde usuarios potenciales lo prueben, o una versión Beta disponible, o un paso a producción para un conjunto acotado y controlado de usuarios.     

PRA04. Realizar reuniones de planificación (y replanificación) frecuentemente (frecuencia de pocas semanas no meses). Planning Meeting.

En las reuniones de planificación el PO acuerda con el equipo el trabajo que espera que se complete en un cierto período de tiempo (en un Sprint o en el Proyecto). Además, en estas reuniones el equipo puede resolver dudas respecto de cada ítem de trabajo para asegurarse que lo interpreta correctamente. De esta forma el PO se hace protagonista en cuanto a las decisiones de negocio. Si estas reuniones de planificación no se realizan con la frecuencia necesaria se corre el riesgo que el equipo asuma decisiones de negocio y/o se vea bloqueado para continuar esperando que se establezca o confirme la planificación. En contextos de trabajo poco planificables, por ejemplo, en mantenimiento de aplicaciones (donde con frecuencia lleguen imprevistos y de carácter urgente), puede que en lugar de reuniones de planificación sea más efectivo que el PO establezca pautas detalladas respecto a priorización y forma de actuar ante los ítems de trabajo que llegan al equipo, de forma que no se requiera la intervención del PO salvo para excepciones. Si el trabajo es más bien planificable (tendrá  sentido invertir tiempo en planificar pues normalmente esa planificación no cambia significativamente) se pueden establecer la fechas de fin de Sprint con antelación, de forma que intentemos garantizar la participación del PO en esas fechas. 

PRA09. Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado. Gestión del Backlog.
El PO por definición es quien debería gestionar el Backlog pues allí están ordenados todos los ítems de trabajo que irán incrementalmente completando el producto, todo desde una perspectiva principalmente de negocio, aunque podría tener ciertos condicionantes técnicos recomendados por el equipo de desarrollo. En esta gestión del Backlog suele ser necesario que el equipo le ayude al PO a identificar y organizar los ítems del Backlog, pero con la confirmación el PO para que esto no conlleve que el equipo tome decisiones de negocio.

PRA17. Product Owner en estrecho contacto con el equipo y altamente disponible.

Aparte de las reuniones programadas con el equipo (Reuniones de Planificación y Reuniones de Revisión) el PO debería estar altamente disponible para resolver dudas y validar el trabajo del equipo de desarrollo. La no disponibilidad provocará posiblemente bloqueo en algún ítem en el que se está trabajando y obligará a trabajar en otro ítem menos prioritario mientras se resuelva dicho bloqueo. Además, las interrupciones asociadas a dejar un ítem sin finalizar y luego retomarlo para continuar perjudican el rendimiento del equipo. Se deben establecer canales y protocolos de comunicación que reduzcan al máximo la espera del equipo por disponibilidad del PO, aunque no necesariamente tenga todo que resolverse por reuniones presenciales con el PO, hay que tener aprovechar también mensajería instantánea, comunicación telefónica y videoconferencias, todo en su justa medida respecto de lo que se requiere comentar con el PO.

PRA18. Perfil cliente del Product Owner. Una persona que prioriza el trabajo del equipo y es un buen representante de los clientes/usuarios.

Scrum define con precisión el perfil esperado del PO, que además de una persona (no un comité) requiere ser un buen representante de la parte cliente (y usuarios), y ojalá con un nivel de autoridad en ellos para impulsar el uso del producto. Si el PO no cumple con estas características puede ser un gran inconveniente puesto que podría orientar el desarrollo del producto en una dirección incorrecta, que no satisfaga las reales necesidades de los usuarios. Por esto, si el PO tiene ciertas debilidades al respecto tendrá que hacer un esfuerzo por buscar apoyos en la parte cliente que complementen su perfil pero manteniendo su papel de PO hacia el equipo de desarrollo, es decir, que esta situación sea lo más transparente posible para el equipo.  

PRA19. Realizar reuniones de revisión del trabajo entregado. Review Meeting.

Similar a los que sucede con las Reuniones de Planificación, en las Reuniones de Revisión el equipo necesita la participación del PO para validar el resultado (aunque aun sea parcial) de su trabajo. Además, estas reuniones deberían también servir para mantener la motivación del equipo cuando el PO confirma que su trabajo está siendo satisfactorio. No debería ser un problema asegurar la participación del PO en estas reuniones si se establece con bastante antelación las fechas de finalización de los Sprints, al menos de los más próximos. Desgraciadamente, en muchos casos, y particularmente cuando se trata de la revisión de una versión que pasará a producción, una revisión detallada no es factible hacerla en puntualmente en una reunión, y requiere que la confirmación del PO se realice después de que haya aplicado pruebas interactuando con la aplicación en un entorno de preproducción. Lo importante es intentar que el equipo de desarrollo no tenga que seguir avanzando mucho más que el próximo Sprint sabiendo que hay una versión de Sprint anterior aún por confirmar en cuanto a posibles flecos. De no ser así, y teniendo varias versiones por confirmar, la gestión de cambios puede complicarse y añadirse ruido durante los Sprints por incorporación tardía de flecos de versiones previas. 

PRA21. Jefe de carácter líder y facilitador en lugar de actitud del jefe autoritario y controlador. Perfil gestor del Product Owner.

Así como el PO debe tener un perfil de cliente, también debe tener un perfil de gestor del trabajo (o del proyecto). Entre las responsabilidades que propone Scrum para el PO encontrados típicas tareas realizadas por un Jefe de Proyecto en cuanto a la gestión de alcance, plazos y costos. Sin embargo, por otra parte se enfatiza que el equipo debe autogestionarse en lo técnico. Por lo tanto, se necesita un PO que sea líder y facilitador más que un jefe autoritario, pues de lo contrario afectaría dicha autogestión que se espera del equipo en cuanto a decisiones técnicas. Es un gran desafío en una transformación ágil la conversión del típico Jefe de Proyectos hacia un perfil acorde con lo que se esperaría de un PO y/o de un Scrum Master. En el caso de PO, ya no debería existir esa autoridad vertical en cuanto a los aspectos técnicos, solo se mantendría en cuanto a las decisiones de negocio y a la gestión del trabajo desde esta perspectiva. En el caso de una conversión hacia Scrum Master, es más desafiante aun pues además de transformarse en apoyo (sin relación de autoridad ni en lo técnico ni en lo de negocio), requiere para ello un profundo conocimiento y experiencia en el enfoque ágil y cómo llevar a cabo la trasformación ágil del equipo.

PRA24. Establecer y comunicar al equipo la visión del producto o servicio y reforzarla regularmente.

Este es otro ingrediente del perfil PO que es muy importante para la orientación del trabajo del equipo de desarrollo. El PO puede mantener el compromiso y motivación del equipo comunicando de forma efectiva su visión del producto y  su estrategia respecto a cómo abordar su desarrollo incremental. Especialmente cuando se producen cambios de prioridades, postergaciones o interrupciones es importante que se expliquen al equipo para mantener alineada la visión técnica con la visión de negocio. Además, el equipo necesita pistas para poder discriminar en su inversión de esfuerzo qué ítems son más críticos para el negocio, y a ellos dedicarle más esfuerzo, ya sea en especificación, en programación y/o en pruebas.  

PRA27. Trabajo centrado en satisfacer pruebas de aceptación acordadas con el Product Owner.

El criterio de éxito al terminar un ítem de trabajo debería estar establecido por la satisfacción de sus pruebas de aceptación, pruebas que el mismo PO podría comprobar, pues se refieren al comportamiento del producto desde una perspectiva externa, de uso del producto. Es más, las propias pruebas de aceptación deberían ser la parte esencial de la especificación de requisitos del producto y según esto deberían estar establecidas antes de llevar a cabo el trabajo de ejecución/implementación de un ítem. n un entorno ideal es el propio PO quien debería especificar en suficiente detalle cada ítem de trabajo que ejecutará el equipo de desarrollo. Sin embargo, lo usual es que el equipo ayude al PO a establecer esta especificación de requisitos y especialmente las pruebas de aceptación que comprobarán que el trabajo realizado ha sido satisfactorio. Cuando no se establecen claras pruebas de aceptación quien ejecuta el trabajo no tiene un "contrato" con lo cual se corres el riesgo de hacer más o menos de lo que se espera. Las pruebas de aceptación acotan el trabajo que debe realizarse. Además, obviamente sirven de guía en para comprobar exhaustivamente que el resultado obtenido es satisfactorio.     

Comentarios finales

Hemos analizado 10 de las 42 prácticas del catálogo Agilev-Roadmap, las más estrechamente asociadas a responsabilidades del PO. Las 10 prácticas son muy importantes de cara a conseguir un mayor y mejor resultado en la transformación ágil. El no poder aplicarlas o no al menos de forma total supondrá una merma en la efectividad de la metodología pero no conlleva que no aplicar el enfoque ágil en su totalidad. Además, como hemos comentado, hay algunas medidas que pueden contrarrestar deficiencias en el PO. Por otra parte, las otras 32 prácticas tienen independencia del desempeño del PO y pueden ser aplicadas por el equipo y con el apoyo del Scrum Master.

"Ser ágil es aplicar prácticas ágiles", mientras más y con más intensidad se apliquen mejor. Pero cuántas prácticas se apliquen y en qué intensidad se aplique cada una de ellas es una cuestión que depende del contexto de trabajo (no todas las prácticas pueden/deben aplicarse). Además, también dependerá del punto en el cual se encuentre la transformación ágil, pues se trata de un proceso un que debería ser progresivo, pues cada práctica conlleva sus desafíos y refinamientos durante su implantación (lectura recomendada: ¿Revolución o evolución hacia la agilidad? ¿Cuál es tú estrategia de Transformación Ágil? ).

Patricio Letelier

twitter.com/yopolt

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

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

5 diferencias entre Historias de Usuario y Casos de Uso

 

Me he decidido a escribir este post después de haber comentado y respondido al respecto de esta duda en repetidas ocasiones. Así pues, es más práctico tener un lugar donde dejar disponible esta información :-).

Los Casos de Uso son parte de la notación UML pero fueron propuestos originalmente por Ivar Jacobson a fines de los 80's. Por otra parte, a Alistair Cockburn se le atribuye la denominación User Story (Historia de Usuario) a fines de los 90's, nombre que se popularizó con el libro de Kent Beck describiendo el método Extreme Programming (XP). 

Antes de entrar en materia hay que remarcar que para el enfoque ágil no hay un estándar, lo cual tiene sus ventajas e inconvenientes :- ). Existen varias propuestas de métodos ágiles (Scrum, Kanban, Lean Development, Extreme Programming, y otros) con información proporcionada por sus autores, y además, mucha literatura adicional con "interpretación" de dichos métodos, del enfoque ágil en general y de la adaptación necesaria al aplicarlos en un contexto específico. Dicho esto, a continuación, paso a comentar "mi interpretación" al respecto :-).

Estas serían algunas de las diferencias destacables entre Casos de Uso (CU) e Historias de Usuario (HU):

1. Las HU son unidades de trabajo que debe abordar el equipo de trabajo, pueden ser cambios en el producto (nuevos requisitos funcionales o no funcionales, mejoras o correcciones de fallos) u otras tareas como montar servidor, preparar demos, etc. Los CU especifican, por defecto, solo requisitos funcionales del producto. Según esto, las HU y los CU coinciden en ser ambos una forma de representar requisitos funcionales, pero las HU además pueden representar otro tipos de trabajo que debe realizar el equipo, tales como mejoras y correcciones en requisitos ya implementados, e incluso otras tareas que no implican un cambio en el producto.
2. Las HU deberían ser en general pequeñas, lo suficiente para que se puedan implementar y probar en un par de días o una semana como máximo. Si son más grandes, se consideran HU "Épicas" y lo más recomendable es que sean abordadas incrementalmente mediante varias HU "más pequeñas" y desarrolladas de forma consecutiva. Los CU no tienen a priori ninguna restricción de tamaño, pero dado que los diagramas de CU muestran visualmente el modelo de requisitos, debería tratarse de abstracciones de mayor nivel. Sin embargo, aprovechando de hacer una crítica "constructiva", a veces me sorprende ver diagramas de CU con muchísimos CU. Esto, en general, se debe a que los CU se están especificando muy asociados a cada operación CRUD relacionada con cada entidad del sistema :-(. Por ejemplo, si tenemos la entidad Usuario, se establecen los CU: "Alta de usuario", "Modificación de usuario", "Eliminación de Usuario" y "Lista de usuarios", y aplicando esta estrategia de forma indiscriminada, si el sistema tiene 50 entidades de dominio el modelo de requisitos tendrá al menos 200 CU!!., los cual posiblemente entorpecerá la organización del desarrollo de las funcionalidades. Otra crítica que suelo hacer es considerar como CU funcionalidades que pueden ser prescindibles en el nivel de abstracción del modelo de requisitos, por ejemplo, incluir el CU "Login" y para más remate ponerlo como <<include>> de todos o casi todos los CU, perjudicando la legibilidad del diagrama. A menos que el "Login" no sea el "estándar", esta funcionalidad entraría en el terreno de lo obvio, lo que no es necesario especificar. Si se trata de un sistema multiusuario obviamente debe tener implementado un mecanismo de autenticación, y esto, por tamaño, podría perfectamente ser una HU.
3. Las HU se terminan en algún momento (en un Sprint, si se trabaja con iteraciones), luego no se vuelve a trabajar en ellas, cualquier "fleco" (mejora o corrección) se establece como una nueva HU. Los CU se mantienen, pueden evolucionar, y no consideran en su especificación las posibles correcciones de fallos que pudiesen tener. Por esto, los CU no son ítems apropiados para ponerlos en una planificación temporal, ya que a menos que no se produzcan mejoras ni correcciones de fallos, un CU nunca se termina. Se podría indicar en una planificación cuándo se comienza el desarrollo de un CU y cuándo se termina una primera versión de él, pero los posteriores cambios ya no serían nuevos CU.
4. Las HU se estiman en Puntos (tamaño relativo a una HU que sirve de referencia) u Horas Ideales (horas ininterrumpidas de trabajo). Los CU en un contexto tradicional suelen estimarse en horas de contrato, es decir, Horas Hombre (HH).
5. La gestión de HU se realiza en el Backlog, que es una lista ordenada de todas las HU no terminadas. Este ordenamiento responde a una priorización establecida por el Product Owner (PO) que determina el orden en el cual se abordarán las HU. Se asume que el Backlog puede cambiar, es decir, pueden añadirse, modificarse o eliminarse HU, pueden agruparse o dividirse en nuevas HU, así como también puede cambiar su ordenamiento. En cambio los CU no conllevan en su aplicación una estrategia de implantación a lo largo del tiempo. Los CU suelen establecerse y especificarse detalladamente al comienzo del desarrollo de un producto, antes de comenzar a construirlo, y posteriormente, al menos el diagrama de CU, no suele tener demasiados cambios (no es usual añadir o eliminar CU durante el desarrollo).

A continuación, mi opinión "arriesgada" :-) respecto de una posible convivencia de CU e HU. He comprobado en la práctica que al inicio del desarrollo de un producto, cuando se están descubriendo sus requisitos, es útil elaborar un diagrama de CU que permita visualizar los actores y CU globales, es decir, lo que equivaldría a en el enfoque ágil a "Features", o también estaría cercano al concepto de HU "Épicas". Se trataría de características funcionales más globales que requisitos software específicos. La visualización de estas funcionalidades globales permite hacerse una idea general de los requisitos y de los tipos de usuarios (actores). Además, si fuese conveniente en este diagrama de CU se podría mostrar jerarquías de actores en el caso de requisitos funcionales específicos para ciertos tipos de actores. Esta identificación de actores y CU globales también es útil posteriormente para contextualizar las HU que se van desarrollando. Por ejemplo, todas las HU que se han implementado en el contexto de un CU estarían fácilmente localizadas en dicho CU. 

En Worki, nuestra herramienta de apoyo para la gestión ágil del trabajo, y según "nuestra interpretación" del enfoque ágil :- ), utilizamos concepto de Unidad de Trabajo (UT) para referirnos a los ítems de trabajo que debe abordar el equipo. Usamos este nombre más general que HU para destacar que puede tratarse de cualquier tipo de trabajo del equipo, sean cambios en el producto u otro tipo de tareas, donde hablar de HU resulta extraño :-). Además, en Worki se ofrece una "Estructura-Temas" para cada producto, la cual se representa como una jerarquía de nodos que pueden representar una jerarquía de descomposición de requisitos. Cada UT se asocia a uno o más nodos de esta estructura, aquellos nodos donde la UT hará algún cambio. 

En cuanto a especificación de requisitos, nuestra recomendación es especificar los cambios en el producto usando mockups y Pruebas de Aceptación, y si fuera el caso, una breve descripción de contexto y justificación del cambio. Así pues, las UT se especifican básicamente mediante mockups y Pruebas de Aceptación. En Worki, tanto las UT como sus Pruebas de Aceptación quedan asociadas a nodos de la "Estructura-Temas" y en cada cono son gestionadas de forma detallada (acciones de creación, modificación, eliminación o ejecución que se realizan en una UT). Así, cada nodo de la "Estructura-Temas" tiene asociadas todas las UT que han realizado cambios en esa funcionalidad y además, acumula todas las Pruebas de Aceptación implementadas por esas UT, las cuales establecen el comportamiento de dicha funcionalidad. 

Lecturas adicionales respecto de este tema:
Discusión en Wiki Wiki Web. http://wiki.c2.com/?UserStoryAndUseCaseComparison

La opinión de Martin Fowler. https://martinfowler.com/bliki/UseCasesAndStories.html

Patricio Letelier

twitter.com/yopolt

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

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

Organización ágil del trabajo: Parte II - Dos dimensiones del trabajo

En este post ilustraré la variedad de alternativas para la organización ágil de una Línea de Trabajo. El concepto de Línea de Trabajo se refiere a un Backlog  (conteniendo el trabajo que hay que hacer) + su Product Owner + su Equipo, encargado de realizar dicho trabajo. Así pues, en un cierto contexto de trabajo podrían existir múltiples Líneas de Trabajo, cada una con una organización del trabajo diferente según sus necesidades.

La organización ágil de trabajo tiene dos dimensiones: Dimensión Contenedor del Trabajo y Dimensión Proceso del Trabajo. En la Dimensión Contenedor del Trabajo por defecto siempre tendremos el Backlog, que es una lista ordenada de Unidades de Trabajo (UT, o llámense ítems o Historias de Usuario). En la Dimensión Proceso del Trabajo tendremos al menos un tablero kanban que refleja el workflow con el cuál abordamos el trabajo. En la siguiente figura se muestra el caso por defecto, tenemos un Backlog y el tablero kanban más simple (To Do, Doing, Done).

La clave está en entender que una UT estará en una determinada posición del orden del Backlog y al mismo tiempo estará en algún estado/actividad del tablero kanban. En la figura se observa que la UT se color naranja está en la parte alta del Backlog (más cerca de terminarse) y en el tablero está en el estado Doing.

Las UT se irán terminando en el Backlog de acuerdo a su orden desde arriba hacia abajo, y las siguientes irían subiendo. Debería existir algún mecanismo para ocultar/mostrar las UT terminadas pues el foco debería centrarse en las UT no terminadas y más prioritarias. Las nuevas UT que lleguen deberían posicionarse en el Backlog compitiendo en prioridad con las ya existentes.

En la siguiente figura se ilustra el caso en el cual el tablero kanban refleja un proceso más detallado que ofrece mayor observabilidad del estado de cada una de las UT. En este caso, por ejemplo, la UT naranja estando en el Backlog como contenedor, al mismo tiempo está en la actividad Diseñar.

En los dos casos anteriores el trabajo se centra en generar un buen flujo de trabajo terminado y siguiendo el orden asignado a las UT, de acuerdo a las prioridades establecidas por el Product Owner. No hay fechas comprometidas para el término de las UT, pero podrían asignarse puntualmente fechas límite para algunas de ellas y hacer un seguimiento al respecto para mantenerlo coherente con el orden asignado a la UT.

Veamos ahora un caso en el cual la Línea de Trabajo tienen regularmente unos compromisos de entrega de UT terminadas. En este caso convendría utilizar Sprints que representan períodos de tiempo (recomendación de no más de un mes de duración), es decir, tienen una fecha de inicio y fin. Si se ponen UT en un Sprint se asume que el esfuerzo asociado a su realización es coherente con la Capacidad del equipo para dicho período. La siguiente figura ilustra el caso en el cual además del Backlog se usan Sprints.

En este caso un conjunto de UT se mueven desde el Backlog al Sprint en el cual se va a ejecutar el trabajo asociado hasta terminarlas. Nuevamente, en este caso tanto si una UT está en el Backlog como si está en un Sprint, al mismo tiempo estará en algún estado/actividad del tablero kanban. Cuando se utilizan Sprints, es importante distinguir dos grupos de estado/actividades en el tablero kanban; columnas de "preparación" de las UT, donde se define con suficiente detalle la UT, y columnas de "ejecución" de las UT, que corresponden al trabajo que se hará dentro del Sprint hasta  terminar la UT. De esta forma la correcta preparación de las UT permite tener una estimación adecuada para establecer el esfuerzo asociado. En este caso la columna "Esperar Sprint" establece dicha división del tablero en "preparación" y "ejecución". En Esperar Sprint se acumulan las UT que ya están preparadas para incluir en un Sprint. En este ejemplo, las actividades Programar y Aplicar Pruebas de Aceptación corresponden al trabajo de ejecución de las UT durante el Sprint.

Aunque podría definirse con anticipación el contenido de UT de varios Sprints futuros no es recomendable, pues los cambios en el contenido de Sprint previos repercutirán en el contenido de Sprint futuros para mantener coherente su relación entre esfuerzo y Capacidad del equipo. Así pues, se sugiere definir el próximo Sprint y cuando se esté agotando comenzar a definir el Sprint siguiente.

Finalmente, en el caso de requerir un seguimiento más detallado de un conjunto de UT que se realizarán durante un período más largo es conveniente asociarles un Proyecto para tener un seguimiento global de las UT.  Pero en este caso también puede ser interesante utilizar Sprints para el seguimiento a corto plazo. Backlog, Sprint y Proyecto son así tres contenedores que se podrían utilizar en conjunto. Una UT estará o no dentro del alcance del Proyecto, y podrían estar en el Backlog o en algún Sprint. En la siguiente imagen se muestra como el Proyecto actúa como contenedor adicional de UT que pueden estar en un Sprint o en el Backlog antes de ser incluidas en un Sprint.

La gestión de alcance del Proyecto se realizaría asociando o no las UT al proyecto. Así, en un Sprint podría haber UT del Proyecto y otras no pertenecientes al Proyecto. Lo mismo pasaría en el Backlog, donde se marcarían las UT que pertenecen al proyecto.

En este punto del post toca pasar la cuña de publicidad de nuestra herramienta Worki :-), la cual hasta donde sé es la única donde se apoya adecuadamente esta doble dimensión de la organización del trabajo. En Worki, cada Línea de Trabajo puede incluso tener asociados varios tableros kanban en caso que se apliquen diferentes procesos a distintos tipos de UT. En Worki aunque las Líneas de Trabajo tengan diferente organización (en cuanto a uso o no de Sprints y/o Proyecto, o se utilicen diversos workflows) se ofrece una visualización integrada de todo el trabajo. Esto se ilustra en la siguiente figura que corresponde a la interfaz de arranque de Worki.

En Worki se ofrecen múltiples vistas de la información facilitando la gestión en contextos multiproyecto o de varios equipos de trabajo, y quizás con personas trabajando en varios equipos. Por ejemplo, en la siguiente figura se muestra un tablero kanban asociado a la información mostrada en la figura anterior.  

En este post también espero haber dejado una vez más en evidencia que no es una buena idea el enfrentar métodos ágiles, promoviendo el uso de uno u otro de forma alternativa. Hemos visto cómo, cuando es conveniente, pueden usarse Sprints (proceso iterativo propuesto por los métodos Scrum y Extreme Programming) junto con un tablero kanban (la esencia del método Kanban). Con lo cual no se trata de aplicar de forma exclusiva Scrum o Kanban (o cualquier otro método ágil), lo sensato es aplicar las prácticas ágiles que nos ofrecen los diferentes métodos, aquellas que sean convenientes para la Línea de Trabajo, e intentar aplicarlas con la mayor profundidad posible. Lectura recomendada: ¿Kanban or Scrum? that is not the question. Si a la organización ágil de Línea de Trabajo le llamamos Scrum, Kanban u otro nombre, eso es un asunto de simplificación, al cual no vale la pena darle más importancia, solo daría para discusiones puristas infructuosas :-).


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

Ecualizador de prácticas ágiles, sintoniza la agilidad de tu equipo de trabajo

De vez en cuando conviene volver a comentar los fundamentos del enfoque ágil, especialmente cuando comprobamos que ser o no ser ágil parece algo bastante difuso o al menos poco consensuado :- ). Hace tiempo ya publiqué un post llamado "¿Qué es ser ágil? ¿por qué debería interesar ser ágil?" en el cual doy mi opinión al respeto. En este post quiero ilustrar con el "Ecualizador de prácticas ágiles" una forma sencilla y visual para mostrar el nivel actual de transformación ágil en un determinado contexto. Ser ágil no es un "todo o nada", más bien es estar en un cierto nivel de agilidad.

Para la explicación utilizaré el catálogo de prácticas ágiles de nuestro enfoque Agilev Roadmap, el cual incluye 42 prácticas ágiles provenientes de los 4 métodos ágiles más populares: Scrum, Kanban, Len Development y Extreme Programming. Este catálogo se muestra en la siguiente figura, en la cual dichas 42 prácticas se ubican en los métodos correspondientes. Resulta evidente que existen ciertas prácticas exclusivas de unos métodos pero también bastantes compartidas, además de 4 prácticas fuera de dichos métodos pero que también considero útiles.

Catálogo de Prácticas de Agilev Roadmap

De esta figura se constata que aplicar en exclusiva un método ágil no parece ser lo más conveniente pues se estarían descartando prácticas que también podrían ser útiles. Es decir, una transformación ágil no debería estar restringida a un determinado método, lo importante son las prácticas que podrían representar una oportunidad de mejora en el contexto donde se van a aplicar, independiente del método ágil del cual provengan. Según esto, podríamos parafrasear "Talk is cheap, show me the code" por "Talk is cheap, show me the agile practices" :-). Básicamente en Agilev Roadmap proponemos un sencillo modelo para ayudar a iniciar una Transformación Ágil (o reconducir una ya iniciada). Dicho modelo se basa en evaluar los objetivos que interesa conseguir, las prácticas que pueden contribuir a ello y los desafíos que podría conllevar la implantación de dichas prácticas. Con lo cual, lo que conseguimos en Agilev Roadmap es visualizar el estado de agilidad de un contexto de trabajo y según eso tomar decisiones respecto a incorporación o intensificación de la aplicación de ciertas de prácticas ágiles. La metáfora de esta evaluación es un ecualizador de prácticas ágiles como el que se muestra a continuación. 

El ecualizador ilustra el nivel de aplicación de cada práctica ágil. Según el contexto y los objetivos de mejora que interesen, la selección de prácticas que deberían aplicarse o intensificar su aplicación son aquellas que más contribuyan a cumplir dichos y que presentes unos desafíos que sean factibles de superar. Cada contexto de trabajo (equipo, línea de trabajo, proyecto, producto, etc.) podría tener su propio ecualizador pues sus objetivos de mejora, la diversidad de su trabajo y las formas de gestionarlo pueden ser diferentes.

En conclusión, ser ágil indudablemente es estar alineado con los valores del Manifiesto Ágil, pero esto, llevado a terreno debe manifestarse en aplicar prácticas ágiles, mientras más y con mayor intensidad mejor pues más significativa será la mejora.


Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com 

Organización ágil del trabajo: Parte I - Líneas de Trabajo

Este post es la continuación de "Un modelo conceptual para la gestión ágil del trabajo", en el cual se explican los conceptos básicos utilizados para gestionar el trabajo usando TUNE-UP Process, nuestro framework para la implantación del enfoque ágil. En este post se se ofrecen pautas para que a partir del modelo conceptual de TUNE-UP Process se establezca una organización del trabajo y de los equipos responsables de realizarlo.

En TUNE-UP Process el trabajo que se quiere organizar está dividido en Unidades de trabajo (UT). Las UT representan lo que solicita el cliente respecto de un producto o servicio, y es lo que reciben las personas encargadas de dar respuesta a dicha solicitud. Es importante destacar que las UT no representan trabajo técnico sino necesidades del cliente respecto de dicho producto o servicio. Como veremos más adelante, el trabajo técnico que requiera cada UT para su realización NO lo consideraremos como nuevas UT sino como actividades por las cuales pasar la UT. La siguiente imagen ilustra una "Parte cliente" que solicita la realización de un conjunto de UT a una "Parte proveedor" (las personas que podrían encargarse de dicho trabajo).

Para que dichas UT solicitadas por el cliente sean eficaz y eficientemente resueltas debe existir una adecuada organización de ese trabajo. Las prácticas ágiles ofrecen muchas oportunidades de mejora en el trabajo. Sin embargo, no basta con aplicar prácticas ágiles, si el trabajo no está bien organizado, probablemente no se conseguirá una mejora significativa usando el enfoque ágil.

TUNE-UP Process utiliza tres dimensiones para organizar el trabajo. A continuación se describen cada una de dichas dimensiones:

• Líneas de trabajo. Cada UT pertenece a una Línea de trabajo. El concepto Línea de trabajo permite diferenciar contextos de trabajo para así poder abordarlos según sus necesidades. Por otra parte, este concepto facilita la asignación de responsabilidad de trabajo a diferentes equipos, o si fuera el mismo equipo, facilitar la distribución de la Capacidad del equipo a cada Línea de trabajo que tenga asignada. Lectura recomendada: El concepto "Línea de trabajo": más allá de Proyectos, Productos o Servicios.
• Contenedores de UT. El contenedor por defecto es el Backlog, cada Línea de trabajo tiene un Backlog. Opcionalmente, una Línea de trabajo puede tener otros contenedores temporales denominados Sprints o Proyectos. 
• Actividades (y/o Estados). Cada UT pasará en mayor o menor medida (según sus necesidades de proceso) por una cadena de actividades que representan el flujo de trabajo (workflow) aplicado a la UT. Esta dimensión representa el o los tableros kanban que tenga asociados la Línea de trabajo. Las actividades pueden variar según el contexto de trabajo pero a modo general se sugieren las siguientes (como columnas de un tablero kanban esencial): Registrar, Ordenar, Preparar, Ejecutar, Probar, y Terminada, las cuales se describen más adelante. 

La siguiente imagen ilustra cómo usando estas tres dimensiones se pueden organizar las UT de un ámbito de trabajo. En la imagen se muestran dos UT, una pertenece a la Línea de trabajo 1, está en el Sprint 2 y está en la actividad Ejecutar, la otra pertenece a la Línea de trabajo 3, está en el Backlog y está en la actividad Preparar.

Algunas restricciones en cuanto a la organización de UT en este espacio tridimensional:

• Una UT pertenece solo a una Línea de trabajo, aunque pueda excepcionalmente cambiar de una Línea de trabajo a otra. 
• Cada Línea de trabajo tiene sus propios contenedores, aunque puedan coincidir sus nombres, de hecho, cada Línea de trabajo tiene siempre el contenedor llamado Backlog.
• El Backlog está siempre abierto para incorporar nuevas UT, sin embargo, los Sprints pueden cerrarse, y con ello, no permitir incorporar  UT adicionales.
• Cada Línea de trabajo, de acuerdo a la naturaleza de sus UT, puede tener asociados diferentes workflows (tableros kanban). Así, a cada UT se le aplica uno de esos workflows asociados, el que mejor se adapte a sus necesidades. 
• Una UT podría estar en más de una actividad al mismo tiempo. Esto puede ocurrir porque el workflow asociado a la UT tiene definidas actividades en paralelo, o porque estando la UT en una actividad, al mismo tiempo se está adelantando parte del trabajo en otra actividad posterior o mejorando/corrigiendo algo ya realizado en otra actividad previa. 

Cada nueva UT se crea en el marco de una Línea de trabajo, y por defecto en su Backlog (podría ponerse directamente en un Sprint que esté abierto) y comenzaría su proceso en la actividad de su workflow. Posteriormente la UT continuaría su proceso pasando por otras actividades, y por otro lado, si la Línea de trabajo utiliza Sprints en algún momento la UT se moverá desde el Backlog a un Sprint para ser terminada. Cuando se usan Sprints lo normal es que en el Backlog se realice la actividad Preparación (trabajo asociado a especificación, estimación, diseño, etc.) y luego al pasar a un Sprint esencialmente se realicen las actividades de Ejecutar (implementar el requisito o cambio) y Probar (comprobar que el cambio ha sido realizado según lo esperado).

¿Cómo empezar a organizar el trabajo de forma ágil?

Mientras mayor sea el ámbito de implantación del enfoque ágil mayores serán los desafíos puesto que probablemente aumentará la diversidad de contextos de trabajo y de personas involucradas. Si bien parece lo ideal es conseguir una tranformación ágil de toda una empresa, puede ser demasiado ambicioso realizarlo todo a la vez. Es por ello que mi recomendación es hacer una implantación acotada a un conjunto reducido de personas que compartan un contexto de trabajo. Lo ideal es que las personas participantes tengan toda su dedicación en el ámbito de trabajo que se va a organizar, así solo tienen que estar aplicando un solo enfoque en todo su trabajo. Para organizar el trabajo deben realizarse las siguientes actividades (no necesariamente en este orden):

• Identificar las Líneas de trabajo. Para comenzar se podría considerar que cada producto o servicio es una Línea de trabajo, cada una de ellas con el nombre de dicho producto o servicio, por ejemplo, si tenemos el producto ACME, establecemos la Línea de trabajo ACME. Veamos ahora otros escenarios. Escenario 1: si (ahora o más adelante) el producto ACME tuviese trabajo de desarrollo, mantenimiento y soporte, podría ser conveniente tener más de una Línea de trabajo asociada al mismo producto, las Líneas de trabajo: ACME Desarrollo, ACME Mantenimiento, y ACME Soporte. Escenario 2: si ACME fuese un producto de gran tamaño y el personal disponible para trabajar en él fuese numeroso, podrían establecerse Líneas de trabajo asociadas a partes (módulos) del producto.Otra consideración importante respecto a la definición de Líneas de trabajo es prever en qué medida interesa tener agrupada o descompuesta la información para el seguimiento del trabajo y según esto separar o unir posibles Líneas de trabajo. Otra consideración adicional es el o los potenciales Product Owner (PO) involucrados, pues si las unidades de trabajo con canalizadas por diferentes PO esto podría sugerir distinguir las Líneas de trabajo según el PO asociado. Por todo esto, vemos que la división o agrupación de Líneas de trabajo dependerá de las necesidades del contexto de trabajo, lo importante es que en todo momento las Líneas de trabajo sean cómodas y efectivas para el PO y para el equipo en cuanto a la gestión del trabajo involucrado. 
• Identificar el Product Owner para cada una de las Líneas de trabajo. Establecer quién o quienes desempeñarán este rol. (ver "Se busca Product Owner ...").
• Establecer el patrón de planificación y seguimiento que utilizará cada Línea de trabajo. ¿Se utilizarán estimaciones? ¿Se hará la estimación en Puntos u Horas Ideales? Si se usan Horas Ideales ¿cuáles actividades se estimarán? ¿Se registrarán tiempos invertidos? ¿Se registrarán tiempos en todas las actividades? Según lo anterior ¿cuáles serán la métricas que se utilizarán para realizar el seguimiento del trabajo en cada Línea de trabajo?.
• Asignar los colaboradores (el equipos) responsables de cada Línea de trabajo. Un equipo puede tener varias líneas asociadas, y en este caso deberá tener pautas claras respecto de la distribución de su capacidad entre ellas.
• Definir los Tableros kanban que necesita cada Línea de trabajo según la actividades que se deben realizar sobre sus UT. El diseño de un tablero kanban podría reutilizarse entre diferentes Líneas de trabajo. Además, una Línea de trabajo puede utilizar varios Tableros kanban, según lo requieran sus UT.
• Para cada Línea de trabajo decidir si se trabajará con Sprints y cuáles serán sus características. Esto lo comento en detalle en el post  Sprints, "welcome to the real world"
• Establecer Proyectos cuando sea necesario. Normalmente un Proyecto se asocia a una Línea de Trabajo, pero podría darse el caso que en un mismo Proyecto se vean involucradas varias Líneas de Trabajo.

Gestión de Portafolio en TUNE-UP Process

Hasta ahora pareciera que le he quitado protagonismo a los Proyectos centrándome en el concepto Línea de trabajo. Sin embargo, los Proyectos no deberían quedar relegados a un simple atributo de una UT, para indicar que la UT está o no en cierto Proyecto. El día a día de las operaciones de una empresa es importante pero también se debe poner especial atención al progreso de los Proyectos que están en marcha pues suelen tener restricciones rigurosas de plazos, recursos y costos. Los Proyectos deberían ser ciudadanos de primera categoría en la organización del trabajo. Por esto, en TUNE-UP Process los Portafolios y sus Proyectos tienen un encaje elegante y potente dentro del mismo marco ya explicado.

En TUNE-UP Process los Portafolios son Líneas de trabajo cuyas UT son Proyectos. De esta forma los Portafolios disponen de todas las facilidades comentadas para las Líneas de trabajo "normales" (que no son Portafolios) y de igual forma las tienen los Proyectos respecto de las facilidades disponibles para UT. La siguiente imagen ilustra el modelo desde la perspectiva de Portafolios y Proyectos. Tal como las UT, los Proyectos también tienen un workflow y en este ejemplo hemos considerado como actividades generales para proyectos Inicio, Preparación, Ejecución y Cierre, sin embargo, podrían ser otras definidas según las necesidades de un tipo de proyecto.

En la figura se muestran dos Proyectos, uno del Portafolio 1 que está en el Sprint llamado 2019 (proyectos previstos para terminarse ese año) y en la actividad Ejecución, el otro del Portafolio 3 en el Sprint llamado 2018 y en la actividad Cierre.  

Un proyecto también actúa como contenedor de UT (las cuales deben terminarse dentro de los plazos del Proyecto). Es por esto que resulta importante disponer de una relación entre un Proyecto y sus UT. Además, un Proyecto podría contener UT de distintas Líneas de trabajo. La siguiente imagen ilustra esta relaciones entre Proyecto y sus UT.

Nótese que las UT de un proyecto pueden pertenecer a diferentes Líneas de trabajo, y también puede darse que algunas UT de una Línea de Trabajo estén asociadas a un proyecto y otras a otro, o incluso UT de Línea de trabajo puede que NO estén asociadas a proyectos. Podría darse también que los proyectos no tengan descomposición (no se descompongan en UT de una Línea de trabajo), con lo cual el proyecto simplemente seguirá su workflow hasta terminar,  hacíéndose todo el trabajo del proyecto en la UT que lo representa.

Líneas de trabajo, Product Owner y Equipos

La organización del trabajo no está completa hasta no establecer para cada Línea de trabajo su Product Owner y el equipo encargado. La siguiente imagen muestra un escenario muy simple e ideal de una Línea de trabajo.

En este escenario ideal el Product Owner centraliza todas las solicitudes de la "parte cliente" y las gestiona ordenándolas y definiéndolas en detalle para que el equipo las vaya procesando y entregando a la "parte cliente". En este escenario de ejemplo no se usan los elementos Sprint ni Proyecto. Recordad que cada línea de trabajo tendrá siempre al menos su Backlog (Sprints y Proyectos se utilizarán solo cuando sea conveniente).  Existen diversas situaciones en cuanto a la combinación de Product Owner, Líneas de trabajo y Equipos. En el post "Se busca Product Owner ..." se presentan algunas de dichas posibles combinaciones desde la perspectiva del Product Owner. 

Si un mismo equipo está encargado de más de una Línea de trabajo debe establecerse cómo distribuirá su Capacidad en cada una de ellas, por ejemplo, dedicar un 50% a cada una, y las mañanas a una y las tardes a otra. Esta decisión no debería tomarla el equipo sino que debería ser negociada entre los Product Owners asociados a las Líneas de trabajo involucradas. Aunque lo ideal sería que un equipo estuviese dedicado un 100% a una sola Línea de trabajo. Esto también es aplicable a nivel de cada integrante del equipo, es decir, lo ideal es que una persona esté dedicada al 100% a un solo equipo.

En un próximo post presentaré Worki, nuestra herramienta que ofrece soporte al modelo y organización del trabajo propuestos por TUNE-UP Process.

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com