Ámbito o contexto de las historias de usuario

Haz clic en la imagen para ampliar y descargar en alta definición

Sigo viendo muchas historias de usuario que más bien parecen historias de ficción y hasta de ciencia ficción: el “usuario” de “historia de usuario” no aparece por ninguna parte.

Ahora vengo con esta imagen, a ver si ayuda. ¿Cómo la ven? ¿Qué les dice? Por favor, déjenmelo saber en el foro.

Para saber más sobre el Contexto de las historias de usuario, o de la cuarta C de las historias de usuario, visita:

http://www.gazafatonarioit.com/2019/06/las-historias-de-usuario-se-cuentan-con.html

También, el User Story Conversation Canvas:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

Cinco formas de mejorar tu desempeño con historias de usuario

 

Imagen tomada de Pixabay

Las historias de usuario no son para escribirlas

La pregunta que debes hacer no es “¿cómo escribir mejores historias de usuario? El objetivo no debe ser escribir historias de usuario. Cámbiala más bien por ¿cómo mejorar mis conversaciones con historias de usuario? Las historias de usuario son un instrumento de comunicación social y sabemos que la forma más efectiva de comunicar información es la conversación, ojalá cara a cara. La forma más efectiva de evolucionar las historias de usuario es vía conversaciones, primero entre los usuarios e interesados y el Product Owner y luego, entre este y los miembros del equipo.

Puedes leer mi artículo Las historias de usuario como instrumentos de negociación para saber más sobre este tema. Clic aquí para leerlo.

Las historias de usuario te ayudan a encontrar tu por qué

Las historias de usuario son una herramienta para iniciar el descubrimiento del producto con el usuario, consumidor o cliente, no es para finalizarlo. De esta manera, tanto el Product Owner, como los desarrolladores (quienes hacen el trabajo finalmente) deberían ver las historias de usuario como algo que describe el por qué están haciendo lo que hacen, no precisamente qué están haciendo. Como siempre, si un usuario no estuvo involucrado en el descubrimiento y desarrollo de las historias de usuario, estas quizás no sean historias de usuario del todo; quizás sean más bien “quimeras imaginadas”.

Conoce a los usuarios

Por eso, mi primerísima recomendación, concisa, si eres responsable de las historias de usuario, es: habla con las personas que tienen la necesidad, el problema, indaga por el problema detrás del problema, la causa raíz. Esto aumentará tu comprensión de lo que se necesita y por qué. Acompaña esta práctica con un conocimiento profundo y empático del usuario o consumidor: quién es, qué hace, con quién lo hace, qué información intercambia y cómo lo hace, son algunas de las cuestiones a escudriñar si quieres tener éxito con historias de usuario.

En mi artículo Qué hay de "usuario" en las historias de usuario profundizo sobre este asunto. Clic aquí para leerlo.

Las historias de usuario y el product backlog

Una historia de usuario no está sola, aislada del resto del producto. Así que es importante pensar sobre ella como un componente de primer orden del product backlog. Y en este punto, es de mucha importancia considerar la transparencia del backlog. Recordemos que transparencia significa que todos los interesados, usuarios y equipo comparten el mismo significado de las cosas, por ejemplo, qué significa que algo está terminado.

Las cosas así, las historias de usuario deben ser transparentes y estar disponibles para todos los interesados, para que estos tengan visibilidad de lo que está haciendo el equipo, en qué orden y por qué. En particular, resuelve preguntas como:

- ¿Los interesados saben cómo acceder a las historias de usuario?

- Cuando acceden a las historias de usuario, ¿el contenido los ilustrará o los confundirá?

En mi artículo El extraño caso de las historias de usuario técnicas pongo de manifiesto que una “historia de usuario técnica” es una práctica disfuncional. Clic aquí para leer el artículo. Este otro artículo también te puede dar ideas al respecto: Buenas y “malas” historias de usuario. Clic aquí para leerlo.

Desarrollo de producto dirigido por hipótesis y experimentos

Las historias de usuario son hipótesis. Trátalas como tal. Haz experimentos y comprueba esas hipótesis. La última línea de defensa es el consumidor final, el usuario. Mientras tanto, no dejarán de ser eso precisamente: supuestos o conjeturas. En este apartado entran en escena las entregas tempranas y frecuentes y, sobre todo, la retroalimentación directa que logres de los clientes o usuarios. Es de esta manera que podrás adaptarte al entorno y tomar mejores decisiones en el futuro inmediato que beneficien a los usuarios. Para lograrlo, tus historias de usuario deben ser realmente pequeñas. Piensa que solo tienes algunas horas para implementarlas o construirlas, hasta unos muy pocos días, dos o tres a lo sumo.

En este apartado, una anotación especial para desarrolladores de software: si todavía te encuentras con el escenario de “mini cascadas”, es decir, primero un “subequipo” desarrolla la historia y luego otro “subequipo” prueba la historia, entonces tus historias de usuario deben ser aún más pequeñas. No te imaginas cómo sufren los analistas de prueba mientras esperan a que desarrollo les entregue las historias para empezar a probar cuando el final del sprint ya está encima. Como siempre, el mejor antídoto contra todo esto, es empezar a cambiar radicalmente las técnicas de desarrollo, incursionando en TDD, BDD y automatización, entre otras. Pero tengo que confesarlo, esto es más fácil decirlo que hacerlo. Por eso hago toda esta recomendación especial.

Quieres saber más

Estos y otros temas de interés hacen parte de mi curso de historias de usuario. En febrero estaré facilitando una nueva edición del curso. Toda la información en https://bit.ly/cursohu.

Historias de Usuario Altamente Efectivas 4

VademeScrum, Sección 2: Las Historias de Usuario 4

Cualidad :: Valiosa (y Valuada)

Las Historias de Usuario deben tener Valor para los usuarios

Veamos esta situación:

Historia de Poco Valor

Como: Lector del blog

Quiero: ver la lista de temas tratados en el blog

Para: buscar las entradas que más se acomoden a mis intereses personales

Es mejor escribir esta historia desde el punto de vista del Bloguero:

Historia de Mucho Valor

Como: Bloguero

Quiero: mostrar a los lectores los nuevos temas tratados en mi blog

Para: que ellos continúen más propensos a leer más entradas del blog

Con esta historia tenemos una perspectiva más clara del valor real de la historia. La implementación de esta podría llevar a más lectores a leer más entradas del blog con lo que se incrementaría el tráfico en el sitio Web y posicionarían al bloguero como experto en los temas de su dominio. Mientras que ambas historias son pequeñas, negociables, independientes, y pueden tener los demás atributos de las buenas historias de usuario, el valor de la segunda es mucho más alto para el negocio que el valor de la primera.

Al negociar la funcionalidad de una historia también tenemos en cuenta su valor para el negocio. Una visión que siempre debemos tener los equipos ágiles es encontrar ese 20% de la funcionalidad que se usa el 80% de las veces o ese 20% del producto que tiene el 80% del valor para el negocio, recordemos que la filosofía ágil se basa en entregar valor al usuario. Esto quiere decir que si tenemos una funcionalidad como la siguiente:

Como: Bloguero

Quiero: ingresar a mi blog con usuario y contraseña

Para: mantener la seguridad y confiabilidad de la información del blog

Criterios de Aceptación:

• Debo ser capaz de cambiar la contraseña cuando lo desee
• El sistema debe enviarme un correo electrónico para confirmar el cambio de contraseña
• El usuario puede ser un nombre seleccionado por mí o una dirección de correo electrónico
• El sistema debe bloquear la cuenta cuando haga tres intentos fallidos consecutivos
• El sistema debe permitir que ingrese automáticamente si uso el mismo computador o dispositivo
• Si olvidé la contraseña, el sistema debe preguntarme por la dirección de correo asociada a mi cuenta o por mi nombre de usuario y enviarme un enlace para establecer una nueva contraseña
• [Siguen…]

Esta es, a todas luces, una historia que se puede dividir en varias historias dado el alto número de criterios de confirmación que tiene. Con los usuarios buscamos lo que proporcione mayor valor para el negocio y lo que se vaya a usar más, por ejemplo: “el sistema debe permitir establecer una nueva contraseña cuando lo desee”, y salir en la primera iteración o entrega con esta funcionalidad. Las demás se van adicionando a medida que avanzan las iteraciones o las entregas. Y como antes, algunos de estos criterios quizás nunca lleguen a implementarse, por ejemplo, el de bloquear la cuenta después de varios intentos errados.

Finalmente, quien mejor conoce el valor de una historia de usuario es precisamente el usuario, personificado en alguien como el Dueño del Producto, que habla como una sola voz ante el equipo de desarrollo y que representa los intereses del negocio. Es a esta persona a quien debemos apoyar para que los esfuerzos de desarrollo sean conducidos efectiva y eficientemente.

A estas alturas solo hace falta recordar que el Valor es el atributo más importante en el modelo INVEST. Cada historia de usuario debe proporcionar algún valor, el mayor posible, al usuario, al cliente o a cualquier interesado en el producto. Con esto en mente, debemos entonces reorientar nuestras estructuras de descomposición funcional del software de un enfoque horizontal a uno vertical, esto es, para el usuario o interesado no tiene prácticamente ningún valor si cierta funcionalidad requiere de uno o varios procedimientos almacenados, o de uno o varios componentes en las capas intermedias de la solución.

El usuario necesita de la funcionalidad que le permite interactuar con el sistema, es lo que tiene valor para él/ella. Entonces debemos crear historias que atraviesen la arquitectura para poder presentar valor al usuario y obtener así la mejor retroalimentación en el menor tiempo posible. Esto es consistente con los modelos de gestión ágiles como Scrum, donde el Dueño de Producto es quien orienta los esfuerzos del equipo de desarrollo y prioriza las historias de usuario teniendo en cuenta su valor para el negocio. Y normalmente el Dueño de Producto no conoce de los aspectos puramente técnicos que subyacen a una historia de usuario (procedimientos almacenados, clases, componentes, Web services, etcétera).

En este punto llegamos al no menos peliagudo asunto de los requisitos técnicos o no funcionales, del software. Dos estrategias se usan habitualmente: la primera de ellas es que estas condiciones técnicas hagan parte de los criterios de aceptación de la historia, como en:

Como: Editor

Quiero: establecer el período de expiración de la contraseña

Para: que los blogueros se vean forzados a cambiar sus contraseñas periódicamente.

Criterios de Aceptación:

• La contraseña se debe poder cambiar antes de finalizar el período de expiración
• Ninguna persona distinta a su creador debe tener acceso a la contraseña

El segundo criterio, relacionado con el acceso a la contraseña, es una restricción típica de seguridad que bien puede ser establecida por un usuario, en este caso, por el Editor; también puede ser un Administrador de la Aplicación. Este enfoque de incluir las características no funcionales de una historia como parte de esta tiene la ventaja de permitir al mismo usuario reconocer su valor y al equipo completo de negociar su implementación.

La segunda táctica es crear historias independientes para cada propiedad o condición técnica, o para un grupo de estas, como en:

Como: Bloguero

Quiero: que mis entradas de blog soporten hasta 10 mil comentarios cada una

Para: mantenerme en contacto con el mayor número de personas posible

Criterios de Aceptación:

• Cada comentario debe contener hasta 500 palabras o 4000 caracteres

En este ejemplo, tanto la acción expuesta en la historia de usuario, como el criterio de confirmación son requisitos no funcionales que se pueden implementar. Este segundo enfoque ayuda a independizar las historias de usuario y a aplicar criterios a un grupo de funcionalidades (este no es el caso en el ejemplo); sin embargo, estas historias tienen la desventaja de que los usuarios o interesados (el Dueño del Producto) no le vean ningún valor y son difíciles de negociar con ellos/ellas.

En la práctica se usa una combinación de las dos estrategias. Ahora bien, hay que decir es que no existe tal cosa como la historia del desarrollador o la del arquitecto del software, ni mucho menos la del Dueño del Producto, como en:

Historias de Poco o Ningún Valor

Como: Desarrollador

Quiero: matricular mi aplicación en Jenkins

Para: tener integración continua automatizada

Como: Arquitecto

Quiero: que las transacciones de la aplicación se tarden menos de 1 segundo

Para: poner en producción una solución de alto desempeño

Como: Analista de Pruebas

Quiero: automatizar los casos de prueba de la aplicación

Para: hacer pruebas de regresión de manera eficiente y efectiva

Como: Desarrollador

Quiero: implementar el procedimiento almacenado spAdicionarComentario

Para: que la aplicación tenga la capacidad de añadir comentarios a las entradas de blogs

Simplemente estas historias no deberían existir, de hecho, no son historias de usuario del todo, ningún usuario final las usa. Para el usuario no es importante, por ejemplo, donde se registran los errores de una aplicación, quizás ni le interese si se registran en alguna herramienta; tampoco es de valor conocer el número de inconformidades que tiene el código fuente frente a las buenas prácticas de programación. El usuario da por hecho que el equipo de desarrollo sabe, precisamente, construir productos de software y que le va a entregar el mejor posible y el de mayor valor.

Conclusiones Finales

Es un hecho, sin importar que tanto trabajemos como equipo de desarrollo en poner a punto el ambiente de pruebas, en tener los mejores servidores de integración continua disponibles, en usar las mejores prácticas de escritura de código fuente, en crear componentes reutilizables de alta calidad o procedimientos almacenados optimizados, el Bloguero de nuestro sistema de publicaciones no puede crear una entrada de blog con el reporte que genera el analizador de código estático de nuestro entorno de desarrollo al compilar el código fuente, ni con las docenas o cientos de procedimientos almacenados implementados sobre el motor de la base de datos, ni con la implementación del algoritmo Blowfish para encriptar las contraseñas.

Simplemente necesita de una interfaz de usuario que pueda utilizar para realizar todas sus operaciones.

Artículos Relacionados

El artículo donde presento las Historias de Usuario, a manera de introducción: Historias de Usuario: un nuevo orden en los requisitos del software, lo encuentran en:

http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

La primera parte de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 1. Lo encuentran en:

http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

La parte 2 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Independiente. Lo encuentran en:

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

La parte 3 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Negociable. Lo encuentran en:

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Referencias

• INVEST in Good Stories, and SMART Tasks:

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

• A User Story Primer, by Dean Leffingwell with Pete Behrens
• User Stories Applied, by Mike Cohn

Casos de Abuso, Parte 12: El Ingeniero de Requisitos es un psíquico

Bueno, esta me la sé también con Analistas, con Diseñadores, con Programadores y hasta con Gerentes de Proyectos. También con usuarios. Cada uno de nosotros piensa que todos los demás en el proyecto están igualmente motivados, que tienen las mismas habilidades, que conocen todo el entorno necesario para entender el sistema. Y No es así. También creemos que los demás piensan como nosotros mismos, que ven el universo como lo vemos nosotros. Y Tampoco es así.

Como receptores de información siempre tenemos un mecanismo infalible: “el qué más.” Como en ¿Qué más debo saber de este proceso? ¿Qué más me puede decir de este modelo? ¿Qué otra cosa esconde este escenario? ¿Quién más necesita esta funcionalidad? ¿En qué otro momento se requiere esta información? Como emisores también debemos estar prestos a brindar toda la información que requiera nuestro interlocutor. ¿Qué más necesita saber? ¿Tiene alguna otra pregunta? ¿Son necesarios más ejemplos? ¿Quiere hablar con alguien más?

Y no me refiero solamente a la comunicación usuario-analista, sino también a la que ocurre al interior del equipo de desarrollo: cuando presentamos los casos de uso, cuando exponemos la arquitectura, cuando mostramos la realización de casos de uso o el modelo de datos y, sobre todo, cuando documentamos el software. Todo esto debemos hacerlo con la premisa de “documentar para el resto”, para el resto de la organización, para el resto del equipo del proyecto, para los usuarios, para los socios de negocios, para los proveedores, incluso para personas ajenas al producto, al proyecto y a la misma compañía, como consultores, expertos del dominio de negocio o técnico y otro tipo de personas. Este es otro de los momentos cuando recomiendo el uso formal de UML y del español (o de algún otro idioma necesario) acorde al público, o sea, terminología del negocio para los usuarios, léxico técnico para los técnicos.

Impacto en la calidad: Medio.

Aquí termina por ahora este análisis, al menos en lo que se refiere a la enumeración de casos de abuso. Volveremos con un capítulo sobre conclusiones y recomendaciones.

Entre tanto, ¿qué otros errores se les ocurren? ¿Qué otros abusos creen que han estado cometiendo ustedes o sus colegas?

No dejen de contarme y lo discutiremos más adelante.

¿Es maduro tu proceso de Ingeniería de Requisitos?

Hace algún tiempo, cuando me involucré en las iniciativas de mejoramiento de procesos de Intergrupo, las que finalmente condujeron a alcanzar el nivel CMMI 5, entendí que la cultura orgánica tiene su propio proceso natural de supervivencia y éxito y que siempre debía medir cuidadosamente lo que es adicionado y es removido de mi entorno. Por supuesto, siempre he tenido claro cuando ser “interno” o “externo” al proceso.

Fue una época en que puse en práctica algunos de los principios memorables de Deming en Administración: “La mejora de procesos debe ser realizada para mejorar el negocio – No como un objetivo en sí misma”. Y empezaba a pregonar que un proceso debe usar prácticas probadas en la industria, no solo la última moda, lo que escuchamos en la conferencia del día anterior o lo que leímos en el último artículo de la IEEE.

Y lo más importante, difundía a mil voces que debemos ser prácticos, que debemos entregar la información que se necesita, cuando se requiere y en un formato que se pueda usar. Con todo esto en mente, usamos un modelo de madurez típico como CMMI para mejorar nuestros procesos. Y uno de los primeros procesos que optimizamos fue este de la Ingeniería de Requisitos.

Pero ¿cómo saber si tu proceso es lo suficientemente maduro? ¿En la práctica qué significa identificar, documentar y administrar requisitos de software de una manera formal y razonable? Según el SEI (siglas en inglés del Instituto de Ingeniería de Software), autor del modelo CMMI, “los requisitos son manejados y las inconsistencias con los planes de proyecto y los productos de trabajo son identificadas”.

Lo que no dice el SEI en su área de proceso de RM (siglas en inglés de Administración de Requisitos), es que esas inconsistencias deben detectarse a tiempo porque cualquier cambio que involucre requisitos es altamente costoso para el proyecto y para los participantes en el mismo.

Para manejar los requisitos, el SEI recomienda:

·         Entender los requisitos

·         Acordar los requisitos con todos los involucrados

·         Administrar los cambios a los requisitos

·         Mantener una rastreabilidad bidireccional de los requisitos

·         Identificar las inconsistencias entre el trabajo del proyecto y los requisitos

Parece sencillo pero quienes hemos trasegado por los vericuetos de la Ingeniería de Requisitos con casos de uso sabemos que es más fácil decirlo que hacerlo y, sobre todo, hacerlo bien. Por ejemplo, sin duda es más simple entender y acordar requisitos entre las personas que están más involucradas en el proyecto, como los Analistas y los usuarios que quienes empiezan a llegar a medida que avanza el ciclo de vida, como los programadores o los certificadores.

Manejar los cambios, naturales por demás en un proyecto típico de software, es muchas veces otro dolor de cabeza para los participantes. Hay quienes creen que una solicitud de cambio es algo de menor valía, cuando la experiencia nos ha enseñado que sea cual fuere el momento y la fuente de la solicitud, siempre hay un impacto significativo y hay costos ocultos que solo los experimentados son capaces de descubrir a tiempo.

Por su parte, mantener una trazabilidad adecuada de los requisitos en ambas direcciones, lo que significa tener un mapa desde las necesidades del usuario y características del software, hasta el código ejecutable, pasando por los casos de prueba y otros artefactos importantes, es algo que solo se puede lograr adecuadamente con el uso de herramientas especializadas. En proyectos pequeños es posible que un Excel sirva, pero en algo más elaborado necesitamos de los instrumentos apropiados.

En cualquier caso, estas prácticas recomendadas (y esta es la palabra clave: “recomendadas”), son apenas un primer escaño para alcanzar la tan ansiada madurez en nuestros procesos de Ingeniería de Requisitos. Volveremos sobre ello más adelante.

Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

Casos de Uso 2.0 puede ser usada en muchos contextos distintos para ayudar a producir muchos tipos de software diferentes.

Aplicable para todos los tipos de sistemas: Mucha gente piensa que los casos de uso son solamente aplicables a sistemas usuario-dependientes, es decir, aquellos donde los usuarios hacen uso intensivo de los mismos, donde hay mucha interacción entre usuarios humanos y el sistema. Esto es extraño porque la idea original de los casos de uso vino de los sistemas telecomunicaciones, que tenían tanto usuarios humanos (suscriptores, operadores) como usuarios máquinas, en forma de sistemas interconectados. Los casos de uso son aplicables para todos los sistemas que son usados.

Casos de Uso 2.0: no es solo para aplicaciones de uso intensivo por usuarios

De hecho, muchos casos de uso son útiles para sistemas embebidos con poca o ninguna interacción humana. Actualmente la gente está usando casos de uso en el desarrollo de cualquier clase de software embebido en dominios tan diversos como el la industria del consumo electrónico, del motor, militar, aeroespacial y médica. Aun sistemas de control de procesos en tiempo real usados para plantas químicas pueden describirse mediante casos de uso, donde cada caso de uso se enfoca en una parte específica del comportamiento del proceso de la planta y de las necesidades de automatización.

Casos de Uso 2.0: no es solo para desarrollo de software

La aplicación de casos de uso no está limitada al desarrollo de software. Estos también pueden ser usados para ayudar a entender los requisitos del negocio, analizar el negocio actual, diseñar nuevos y mejores procesos de negocio, y explotar el poder de la IT para transformar el negocio. Usando casos de uso recursivamente para (1) modelar el negocio y sus interacciones con el mundo exterior y (2) modelar los sistemas necesarios para soportar y mejorar el negocio, es posible identificar fácilmente donde el sistema impactará el negocio y cuales sistemas son necesarios para soportar el negocio.

Los casos de uso usados para modelar el negocio son muchas veces referenciados como casos de uso del negocio. Estos proporcionan el contexto para el trabajo de desarrollo de sistemas de la IT, permitiendo que el desarrollo del negocio y el desarrollo de la IT se lleven a cabo de manera sincronizada. No solo es posible desarrollar los sistemas IT porción por porción sino que también es posible desarrollar el modelo del negocio porción por porción. Esto es muy poderoso porque permite evolucionar el negocio y sus sistemas de apoyo en conjunto unos con otros, habilitando el desarrollo incremental del negocio así como el desarrollo incremental de los sistemas.

En el mundo moderno, el negocio y los sistemas de la IT que lo soportan pueden, y deberían, ser desarrollados en sincronización (uno no trabajará sin el otro). El uso de casos de uso y de porciones de casos de uso tanto en el negocio como en la IT puede cerrar la brecha entre el negocio y la IT habilitando el trabajo como socios colaborativos verdaderos.

Sobre el Papel del Analista Funcional y la Reunión de Presentación de Casos de Uso

Sobre el Analista Funcional

Uno de los errores más comunes que se comenten a la hora de hacer análisis funcional es pensar solo en el presente, en resolver la situación actual, cuando se debería pensar en el futuro, hacía donde quiere ir la organización, cuál es su misión, cuál es su visión y con qué cuenta para llegar hasta allá.

De nada sirve resolver el problema presente si al día siguiente se nos van a presentar otros. En este caso, la anticipación es la clave y más que ello, la visión que tengan los analistas funcionales de hacia donde se va a mover el mercado, el conocimiento de las tendencias, los movimientos de la competencia, las expectativas de los clientes, las corrientes tecnológicas, los rumbos de la economía, entre otros aspectos significativos.

Es allí donde precisamente los indicadores de gestión juegan un papel de apoyo a la hora de tomar las mejores decisiones, aquellas que permitan ir en la dirección correcta. Esa es la trascendencia del Analista Funcional, muchas veces poco vislumbrada en nuestro ámbito, pero real y necesaria. No se trata solo de un asunto de modelamiento de requisitos, se trata de modelar toda una organización y de su perspectiva de supervivencia en el tiempo y en el medio ambiente que la rodea.

Sobre la Reunión de Presentación de Requisitos

Es altamente recomendable que los participantes de la reunión también sirvan como “revisores pares”. Es decir, todos debemos contribuir a que el producto resulte de la mejor calidad posible y esta es una muy buena oportunidad para hacer una gran intervención.

Cada participante bien podría “correr” una lista de chequeo similar, para que la revisión sea lo menos subjetiva posible y para que haya cierta homogeneidad. Esta revisión debería buscar errores de forma, apuntar en principio a aquellos atributos que mencioné en la presentación inicial de este debate, como la claridad, la atomicidad y la precisión de los requisitos y casos de uso, entre otros atributos. 

Pero también, si es posible, buscar errores de contenido, del “negocio”, aspectos que bien pudieron omitirse por parte del Analista Funcional, quizás por considerarlos sobrentendidos o quizás porque nadie se percató de ello con anterioridad. Por ejemplo, revisar si faltaron aspectos contables o regulaciones legales por especificar, o si no se consideraron a ciertos interesados (léase “stakeholders”) externos, como agencias auditoras o supervisoras del gobierno. 

Para todo esto sirve esta primera presentación al resto del equipo y por ello es que la lectura por parte de todos es ineludible.

Sobre “interpretación” vs. “realización” de casos de uso

Algo que ocurre muchas veces es que todos los miembros en un equipo de proyecto de software esperan que en la documentación de requisitos, en general, y de casos de uso, en particular, esté incluido no solo la especificación de requisitos (funcionales y no funcionales), la definición del problema y sus detalles, sino también la solución de ese problema en términos de software.

Es decir, esperamos que la especificación de un caso de uso, por ejemplo, contenga los elementos básicos de un caso de uso, como el Actor, la secuencia básica y las alternativas (si existen), las pre y pos-condiciones y los requisitos especiales, entre otras. Pero también esperamos que tenga la así llamada “realización del caso de uso”. 

Esta no es más que el análisis y diseño del caso de uso, o sea, la manera como se va a implementar ese caso de uso en términos de diseño. Normalmente para esto usamos diagramas de UML, los que sean necesarios, empezando por diagramas de interacción (ya sean de Secuencia o de Comunicación), y también diagramas de Estado o de Actividad, entre otros.

El asunto es que la especificación del caso de uso debe ser lo suficientemente clara (no ambigua) y completa para que cualquier “interpretación” que se haga de la misma arroje los mismos resultados. Y esto debe ser así no solo para el equipo de diseño y de programación, sino para el equipo de pruebas. Es decir, la documentación debe ser tal que el diseñador y el verificador se hagan el mismo modelo o esquema mental del diseño y de las pruebas (casos de prueba) respectivamente.

Algunas técnicas para mejorar la especificación de requisitos (y de casos de uso) incluyen la revisión par, que debe comprender revisión de forma y de contenido. Esta revisión debe validar que cada requisito (y cada caso de uso) cumpla con algunas características bien conocidas:

• Claro
• Atómico
• No ambiguo
• Verificable
• Necesario
• Priorizado

Entre tanto, la especificación de requisitos (incluyendo todos los casos de uso) debe ser:

• Correcta
• Independiente de diseño
• Completa
• Consistente
• Rastreable
• Modificable / Extensible

Para finalizar, los Analistas Funcionales deben presentar esta especificación al equipo de diseño, construcción y pruebas. Este es un paso muy importante que muchas veces se omite o se cumple con simplemente enviar un mensaje electrónico que incluye los documentos relacionados. El objetivo de la presentación no debe ser únicamente exhibir la especificación, sino lograr que todos los involucrados en el equipo salgan con las mismas ideas, con el mismo mapa mental del que hablaba antes.

*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /
PD. Los invito a leer mi artículo sobre Realización de Casos de Uso. Lo encuentran en el enlace adjunto: http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html

Casos de Uso 2.0 y Métodos Ágiles

Quienes ven un sabor “ágil” en la práctica Casos de Uso 2.0, como la expone Jacobson, no se equivocan. Esta es una práctica escalable y ágil que puede ser usada junto a prácticas administrativas y técnicas seleccionadas para apoyar el desarrollo exitoso de software y otras formas de sistemas. Su primera característica es que es una práctica liviana y fácil de usar. De hecho, los autores comienzan diciendo que la guía (se refieren al eBook Use Case 2.0 - Guía Definitiva), describe como aplicar casos de uso de una manera “ágil” y escalable. Y estos dos conceptos se extienden a lo largo de cada una de las páginas del documento.

El concepto de “incrementos” y de “historias de usuario”, generalizado en toda la práctica, es inherente a los métodos ágiles como Scrum. De hecho Casos de Uso 2.0 hace referencia a técnicas como el de “Backlog del producto” también usada en los Sprints o iteraciones de Scrum. el backlog (Product Backlog en Scrum) se crea con casos de uso, historias de usuario y porciones de casos de uso, o una combinación de todas estas.

Pero también es importante aclarar que esta técnica no es una franquicia solo para estrategias ágiles. También puede ser usada con otros métodos o procesos como RUP o MSF. La práctica “no es solo aplicable a pequeños equipos ágiles ubicados en una misma oficina, sino que también es para grandes equipos distribuidos que desarrollan de multi-sistemas complejos.” 

Para precisar mi punto quiero referirme al “principio 5: Entregar el sistema en incrementos”, del que habla la guía en el primer capítulo.

En este apartado, los metodólogos enfatizan que “la mayoría de los sistemas de software evolucionan a través de muchas generaciones. Estos no son producidos de una sola vez, sino que son construidos como una serie de versiones, cada una de las cuales es implementada sobre la anterior. Aun las versiones mismas no son producidas de un solo tirón, sino que evolucionan a través de una serie de incrementos. Cada incremento arroja una versión demostrable o usable del sistema. Cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. Esta es la forma en que todos los sistemas deberían ser producidos.”

Más adelante remarcan: “Las porciones de casos de uso son una herramienta fabulosa para construir incrementos más pequeños en forma de una versión completa. Esta herramienta permite apuntar independientemente a porciones implementables y verificables de los incrementos, asegurando que cada incremento sea más grande que, y esté construido sobre, el anterior.” El concepto es a todas luces aplicable tanto a los métodos ágiles como a los no ágiles.

PD. Para quienes entran tarde a la sintonía, estoy extendiendo el tema de Casos de Uso 2.0, que inicié hace algunos días en otra entrada. Lo pueden encontrar en http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html