lunes, 30 de noviembre de 2020

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


Patricio Letelier

sábado, 11 de abril de 2020

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

www.tuneupprocess.com 




jueves, 20 de febrero de 2020

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


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

www.tuneupprocess.com