Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Analista Funcional. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Analista Funcional. Mostrar todas las entradas

lunes, mayo 04, 2015

Libro: ‘La práctica de inteligencia de negocios: guías para lograr proyectos exitosos’

“El escritor escribe su libro para explicarse a sí mismo lo que no se puede explicar.”
[Gabriel García Márquez, escritor colombiano]

Siempre me da mucho placer realizar este tipo de anuncios. Conozco a Mauricio hace casi dos décadas y hemos tenido la oportunidad de trabajar juntos en distintos proyectos, incluyendo algunos de Inteligencia de Negocios, y de compartir más allá de la práctica profesional. Sé de su pasión por la lectura, por los hechos de la Historia y conozco también del esfuerzo monumental que es escribir y más si se trata de un libro como este. Por eso sé que para Mauro escribir este volumen se convirtió en una osadía, pero finalmente está aquí, el fruto de muchísimas horas de desvelo y estudio.

En el libro, Mauro nos embarca en una lectura amena que inicia con los conceptos generales de la práctica de la Inteligencia de Negocios, pasando por el propósito y los elementos de la práctica, los métodos y las herramientas usadas, lo que él llama ‘la hoja de ruta de un proyecto de Inteligencia de Negocios’ y dedica capítulos enteros a temas vitales como las pruebas y la calidad del producto, el despliegue, gestión de cambios y actividades posteriores a la implantación, hasta llegar a la infraestructura requerida en los proyectos de inteligencia de negocios.

De todo esto, el capítulo VI es mi favorito, porque habla de las personas y de la relación cliente – proveedor, asunto natural cuando se trata de una organización orientada a los servicios de tecnología de la información. Mauro habla de los roles principales a tener en cuenta cuando se trata de tener éxito en los proyectos y en particular dedica una sección a los roles típicos en las organizaciones con iniciativas de Inteligencia de Negocios.

Y a través de todo el texto, Mauro también aborda el tema de cómo se implementan todos estos elementos con métodos y prácticas ágiles como Scrum. De tal suerte que este es un compendio sensato de lo que cualquier interesado, persona u organización, debe tener en cuenta al momento de llevar a cabo proyectos de Inteligencia de Negocios.

Contraportada de 'La práctica de inteligencia de negocios' de Mauricio Cotes
Una de mis partes favoritas en todo el libro tiene que ver con el uso de las metodologías. El pensamiento de Mauro no se circunscribe a un método en particular, permitiendo la elección al lector. Eso es excelente, porque no entra y no promueve  o siembra elementos dogmáticos en el texto, es una apertura sistémica.

De hecho, su ‘conclusión en relación con el uso de las metodologías’ es algo que no solo es aplicable a proyectos de Inteligencia de Negocios. Mauro nos dice:
 “Finalmente, es ideal que el proveedor tenga la posibilidad de configurar la metodología de manera tradicional o ágil dependiendo de las condiciones, premisas y la negociación hecha con el cliente. El cuerpo metodológico seleccionado debe ser configurable, debe estar documentado, los practicantes deben aprehenderlo y ser conscientes del propósito de cada uno de los elementos que lo constituyen.
Los practicantes de los roles encargados de la contratación y negociación deben tener en cuenta las premisas mencionadas y ofrecer la modalidad apropiada de trabajo según el caso.”
En definitiva, en ‘La práctica de inteligencia de negocios’, Mauro saca a relucir sus veinte años de experiencia en el tema. Es un libro escrito desde la pragmática del autor, con el suficiente soporte teórico, pero sobre todo, con la idiosincrasia nuestra, la del trópico, con la visión de nuestra economía y de nuestra forma de hacer proyectos, lo que lo convierte en un documento valioso para cualquier estudiante y profesional y para cualquier organización que piense en serio acerca de la práctica de la inteligencia de negocios.

Es un trabajo minucioso, que te ha costado encorvarte durante muchísimas y largas horas, pero finalmente tú y todos nosotros tenemos la mejor recompensa: un sumario de todo tu fogueo en el asunto. ¡Enhorabuena, Mauro, felicidades por este gran logro!

¿Quieres conseguir el libro?

Escríbanle un mensaje electrónico a Mauro a la dirección: rmcotes@hotmail.com. Él les dará más detalles de cómo obtenerlo.

lunes, agosto 19, 2013

Historias de Usuario Altamente Efectivas 4

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

Cualidad :: Valiosa (y Valuada)

Escribiendo Historias de Usuario Altamente Efectivas, 4
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:
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:
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:
Referencias
  • INVEST in Good Stories, and SMART Tasks:

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


miércoles, julio 31, 2013

Historias de Usuario Altamente Efectivas, Parte 1

Escribir Historias de Usuario Altamente Efectivas
VademeScrum, Sección 2: Las Historias de Usuario 2

Veamos algunos ejemplos de historias de usuario, al menos, en lo que tiene que ver con su primera parte, la así llamada Carta (de Intención) de la historia:
Ejemplo 1:
Como: editor <<Rol>>
Quiero: leer un libro <<Actividad>>
Para: estudiar la viabilidad de publicarlo <<Valor para el negocio>>
Ejemplo 2:
Como: bloguero
Quiero: recibir alertas de los comentarios hechos por mis lectores
Para: responder los comentarios lo más pronto posible y mantener una comunicación fluida con mis lectores
Ejemplo 3:
Como: miembro de la red social
Quiero: ser capaz de cambiar mi contraseña de acceso
Para: evitar suplantaciones de identidad o accesos no autorizados a mi cuenta
Ejemplo 4:
Como: usuario del cajero electrónico (ATM)
Quiero: programar el pago de mi factura de servicios públicos
Para: viajar tranquilamente sin que me suspendan los servicios y no perder tiempo haciendo diligencias innecesarias
Recordemos que el Rol representa quien está ejecutando la acción o quizás quien está recibiendo el valor de la actividad. Normalmente se refiere a un grupo de usuarios o puede ser incluso otro sistema, si es el que ha iniciado la actividad. Entre tanto, la Actividad representa la acción a ser ejecutada por el sistema y el Valor para el Negocio representa el valor de la funcionalidad para el negocio y para los usuarios que la ejecutan. Esta forma de historia de usuario, llamada a veces “la voz de la historia de usuario”, mejora significativamente el entendimiento del por qué y el  cómo que los desarrolladores necesitan para implementar un sistema que cumpla verdaderamente las necesidades de los usuarios.
Cada elemento proporciona un contexto importante y expansivo. El rol permite una segmentación de la funcionalidad del producto y típicamente genera otras necesidades basadas en ese rol y también suministra un contexto para la actividad. La actividad típicamente representa el ‘requisito’ necesitado por el rol. Y el valor comunica por qué es necesaria la actividad, la cual puede conducir muchas veces al equipo a encontrar posibles actividades alternativas que pueden proveer el mismo valor con menos esfuerzo.
Obsérvese que el valor puede ser distinto para el mismo rol y para la misma actividad. Por ejemplo, otros “blogueros” podrían querer el sistema para:
  • Brindar un mejor servicio al cliente (cuando se trata de un negocio)
  • Crear o incrementar el tráfico hacia un sitio específico
  • Lograr reconocimiento
  • Tener una voz (hacerse con una voz)
  • Para que la gente lo encuentre (un independiente, por ejemplo)
  • Ofrecer mis propios productos y servicios
  • Lograr un crecimiento profesional a largo plazo y continuo
  • Recibir retroalimentación “temprana” sobre los temas tratados para escribir un libro
  • Etcétera

Cada uno de estos valores o metas para el negocio generan o pueden generar historias distintas. Ahora bien, todas estas historias tienen algunas cosas en común:
  • Son independientes unas de otras, aun si representaran características del mismo sistema.
  • Sus características y su intención se pueden negociar entre el equipo de desarrollo y el usuario.
  • Tienen cierto valor para el usuario, unas más que otras.
  • El esfuerzo requerido para su construcción, es decir, para su conversión a una funcionalidad de software, se puede estimar con muy poco trabajo, usando técnicas simples.
  • Son pequeñas, en el sentido de sucintas, y la funcionalidad que se produce a partir de ellas también.
  • Sus criterios de aceptación y su funcionalidad se pueden certificar, es decir, verificar y validar mediante un procedimiento sencillo y viable, tanto en lo económico como en lo técnico.

Estos aspectos comunes constituyen lo que se conoce como los atributos INVEST de las historias de usuario. INVEST es un acrónimo acuñado por Bill Wake para referirse a ciertas propiedades que deberían tener una buena historia de usuario:
  • Independiente
  • Negociable
  • Valiosa
  • Estimable
  • Sucinta
  • cerTificable

En inglés Independent, Negotiable, Valuable, Estimable, Small (o Sized appropriately) y Testable.
En las siguientes entradas abordaré en detalle cada una de estas cualidades.

miércoles, abril 17, 2013

¿Es usted la persona correcta para responder mis preguntas? O el síndrome del sujeto equivocado



En los proyectos de software estamos llenos de personas que no son “las adecuadas para responder nuestras preguntas”, para establecer las verdaderas necesidades del negocio, para darnos a conocer el problema que tienen, el problema detrás del problema, la causa raíz, el impacto de ese problema y las áreas impactadas. Estamos llenos de personas que constantemente no toman decisiones, que tienen que consultar con alguien más, que no entienden lo que nos están contando durante un proceso típico de educción de requisitos, es decir, durante las entrevistas, al responder cuestionarios o al analizar prototipos, entre otras actividades.

Por eso es que nuestros proyectos están repletos de supuestos, algo con lo que nunca debemos trabajar, sobre todo, porque son supuestos pasivos, que nunca evolucionan ni son gestionados con eficacia. Los supuestos le están haciendo mucho daño a la industria y conducen a la producción de software de baja calidad o que no satisface para nada las necesidades de nuestros usuarios y clientes. Hacemos suposiciones porque nuestra mente es muy sabia y siempre necesita respuestas, necesita comprender lo que pasa en nuestro entorno, y si no se produce la respuesta que requiere, entonces la presume.

Esta necesidad de hacer supuestos es inherente al ser humano: a lo largo de nuestras vidas hay cientos o miles de preguntas que no somos capaces de manifestar explícitamente y, por consiguiente, no conseguimos las respuestas adecuadas. De todas estas preguntas sin responder, hacemos suposiciones para llenar el vacío y la insatisfacción que sobreviene, es la única manera de sentirnos seguros. Si logramos respuestas a medias, hacemos suposiciones, si no obtenemos respuestas, también hacemos suposiciones, nos da lo mismo saber si la respuesta es la correcta o no, simplemente es suficiente con suplir el ansia de saber.

Debido a ello, cuando un interlocutor, un usuario u otra clase de interesado, nos está respondiendo preguntas vía entrevista y nos dice que no está seguro, que va a confirmar tal o cual asunto, que debe reunirse la próxima semana con una o más personas para aclarar un tema, etcétera, nosotros, ni cortos ni perezosos, hacemos supuestos. Es más, nuestros productos de trabajo tienen siempre una sección de Supuestos en la que registramos estas conjeturas y muchas veces no las volvemos a revisar. Mi primer consejo es eliminar esta sección de los documentos, son perjudiciales.

También es bien sabido que los usuarios típicamente no saben lo que el software puede hacer o no tienen las habilidades para sintetizar las soluciones basadas en software a sus problemas reales. Y nosotros muchas veces fallamos al preguntar porque somos propensos a creer que el problema de los usuarios es de índole tecnológica y no algo puramente del negocio. Incluso, antes de eso, fallamos al seleccionar y clasificar correctamente a los usuarios correctos o alguien más toma la decisión por nosotros, lo que deja el proyecto en una incertidumbre mayor que aquella con la que inició.

Los supuestos son atajos hacia la veracidad. El problema es que casi nunca acertamos al escoger el camino apropiado. Siempre que sea posible, reemplacemos esas hipótesis por hechos probados, por evidencias que soporten la toma de decisiones, seleccionando mejor nuestros usuarios, entrevistando al mayor número de personas en el menor tiempo posible, así estaremos en capacidad de verificar las fuentes, de contrastar respuestas y de saber cuándo hemos llegado a la definición correcta del sistema. Invite a varias personas a la sesiones de búsqueda de requisitos, la probabilidad de que una de ellas sea la adecuada aumenta.

Por eso, la siguiente ocasión que inicie un proyecto de software y le toque entrevistar por primera vez a un usuario, pregúntele: ¿Es usted la persona correcta para responder mis preguntas? Sí, ya sé lo que van a decir, en nuestra cultura este tipo de preguntas es fuerte y puede tomarse como una insolencia; es cierto. Por eso tenemos alternativas: ¿quién más cree usted que puede ayudarnos a resolver estas cuestiones? ¿Alguien más está interesado en esta situación? ¿Quién más tiene este problema? ¿Alguien más nos puede acompañar en la reunión? ¿A quién podríamos enviarle estas preguntas? ¿Alguien más puede tomar decisiones cuando usted no está?

¡Las posibilidades son infinitas!

miércoles, enero 23, 2013

¿Por qué existe Casos de Uso 2.0?


Necesitamos prácticas que nos apasionen y que se enfoquen en las personas sobre los procesos pero que además nos posibiliten resultados de calidad. Necesitamos además que nuestro trabajo sea aún más colaborativo y permita una integración unificada, continua. Precisamos de un enfoque que permita bajar la tensión “ellos versus nosotros” entre desarrolladores y verificadores.

Requerimos prácticas que nos licencien para manejar mejor los cambios y que nos habiliten para entregar productos de manera incremental. Y también necesitamos prácticas que soporten un mejor manejo del conocimiento de los productos que construimos y que nos apoyen cuando hacemos frente a situaciones adversas, que nos permitan mantenernos enfocados en lo que es de valor para nuestro cliente.

Casos de Uso 2.0 es precisamente eso, una práctica escalable y ágil que usa casos de uso para capturar un conjunto de requisitos y conducir el desarrollo incremental de un sistema que los ejecute. Casos de Uso 2.0 se reenfoca en lo esencial y ofrece una forma de trabajo liviana y más limpia para que los equipos de software logren los beneficios del desarrollo iterativo e incremental a un nivel corporativo.

Pero para llegar más al corazón de Casos de Uso 2.0, necesitamos mirar la radiografía de los casos de uso: ¿Qué hizo tan popular a los casos de uso? Con el tiempo, los casos de uso alcanzaron un uso multitudinario porque comunican efectivamente lo que el sistema debe hacer, porque ponen los requisitos en el contexto de las metas de un usuario específico y porque conducen el desarrollo a través del diseño, el código y, si se quiere, las pruebas.

En el fondo, el modelado de casos de uso es una idea muy simple. Esto quiere decir que con Actores, Casos de Uso, Inclusiones y algunos otros artilugios podemos llegar al núcleo de lo que el sistema debe hacer, porque nos enfoca inequívocamente en quién (o qué) usará el sistema y nos permite encontrar con rapidez asombrosa lo que el sistema debe hacer para que ese quién logre algo útil en su proceso de negocio.

Otra pregunta que debemos responder antes de dar el salto de versión es ¿por qué necesitamos casos de uso todavía? Si hay muchas otras prácticas relacionadas de requisitos populares, ¿por qué estás no han reemplazado la necesidad de casos de uso? Por ejemplo, las historias de usuario son grandiosas para sistemas pequeños y equipos pequeños, aunque bien es cierto que con pequeños incrementos podemos construir un sistema grande.

También hay otros enfoques, como la especificación de características, fabulosa para manejo de productos; los tradicionales requisitos declarativos, excelsos para capturar cualidades independientes atómicas; el modelado de dominio, extraordinario para sistemas de funcionalidad simple y ricos en información. Sí, hay muchas otras buenas técnicas pero a todas les hace falto algo para reunirlas y proporcionar una solución simple y escalable.

Ahora sí, ¿por qué necesitamos casos de uso 2.0? En principio, para corregir algunos de los malentendidos:

  • Los casos de uso son livianos, no pesados
  • Los casos de uso son historias, no funciones
  • Los casos de uso son simples, no complicados
  • Los casos de uso son para todo tipo de desarrollo, no solo para desarrollo de aplicaciones nuevas y “planas”.
  • Para reenfocarnos en lo esencial, de vez en cuando viene bien un refrescamiento de ideas y de experiencias.
  • Para dar un mejor soporte a las innovaciones y mejoras tales como Desarrollo Dirigido por Pruebas (TDD), Kanban y Scrum.

Lo que hace distintivo a Casos de Uso 2.0 es que nos ayudan a entender el cuadro completo, es una práctica tan liviana como queremos que sea, habilita la entrega incremental del producto, no es solo sobre requisitos, es para todo el ciclo de vida, también es para requisitos no funcionales, para software embebido, incluso no es solo para desarrollo de software, también es para desarrollo de negocios y, finalmente, es escalable en todas las direcciones para cubrir cualquier necesidad real.

Como siempre, cuando se trata de procesos y métodos, aconsejo no desvirtuar la capacidad que tenemos los seres humanos de pensar. Lo que posibilitan las técnicas es precisamente potenciar nuestra habilidad para encontrar el mejor siguiente paso en el camino hacia la satisfacción. Al final de cuentas es el cerebro humano el que visiona productos e ideas, ninguna tecnología ni método puede reemplazar nuestro proceso de pensamiento.


Referencias

El e-Book "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso, lo pueden encontrar en www.ivarjacobson.com.

Sobre Casos de Uso 2.0 pueden leer mi serie de artículos en este Gazafatonario IT:

Casos de Uso 2.0

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20.html 

Casos de Uso 2.0 y Métodos Ágiles

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

¡Quiero una Porción de Caso de Uso!

http://www.gazafatonarioit.com/2012/04/quiero-una-porcion-de-caso-de-uso.html

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

http://www.gazafatonarioit.com/2012/04/casos-de-uso-20-aplicable-todos-los.html 

Casos de Uso 2.0: Cosas con las cuales trabajar

http://www.gazafatonarioit.com/2012/11/casos-de-uso-20-cosas-con-las-cuales.html 

Sobre Casos de Uso pueden leer toda mi sección de Lecturas Fundamentales en este mismo Gazafatonario, empezando en:

http://www.gazafatonarioit.com/2006/11/lecturas-fundamentales.html


jueves, diciembre 06, 2012

El extraño caso del caso de uso faltante

O de cómo nunca deberíamos aceptar especificaciones de software incompletas

Los productos de software de alta calidad dependen de la completitud de los requisitos. En general, la calidad de los requisitos de software afecta la calidad de los productos de software. Los Ingenieros de Requisitos o Analistas Funcionales intentamos llenar los vacíos en la especificación del software de manera distinta, dependiendo de nuestra experiencia y del proyecto en el que se encuentren, de factores como el tiempo, la relación con el usuario, la disponibilidad de este o del grado de estabilidad de los requisitos existentes.

Algunos Analistas, por ejemplo, intentamos obtener retroalimentación de los usuarios, mientras que otros acuden a distintos interesados o a fuentes alternas de los requisitos, pero cuando no tenemos ese privilegio, simplemente hacemos suposiciones. Estas últimas pueden ser implícitas o explícitas. Las suposiciones explícitas son preferibles a las implícitas porque podemos validar aquellas posteriormente, mientras que las implícitas llegan a las fases de diseño e implementación con una alta probabilidad de estar erradas.
Ya sabemos que los requisitos de software deben ser: correctos, precisos, completos, consistentes, clasificados, verificables, modificables y trazables. Las especificaciones de requisitos completas y correctas son las requeridas por los desarrolladores para saber qué construir y por los usuarios para saber qué esperar. Una especificación de requisitos de software completa debe incluir toda la información necesaria, incluyendo restricciones y condiciones.
Ahora bien, independientemente de las técnicas de recolección de requisitos, el involucramiento del usuario es un elemento importante, ya que los requisitos vienen principalmente de las personas, no de los documentos o los sistemas existentes. Los usuarios deben ser escuchados cuidadosamente y nunca debemos hacer suposiciones implícitas puesto que estas no se comparten con los interesados aumentando así la incertidumbre en los requisitos. 
De mi propia experiencia, de la de mis colegas, y de estudios en la materia, he llegado a la conclusión de que, nosotros, los Ingenieros de Requisitos, tendemos a ser más rigurosos en la especificación de requisitos cuando:

  • El cliente es de corte militar, es decir, es un cliente rígido, con un proceso formal bien definido o es vigilado por entidades internas o externas a su organización y a las que debe rendir cuentas sobre sus acciones.
  • El análisis de requisitos hace parte de la fase actual del ciclo de vida del software, por ejemplo, cuando estamos en las fases de Inicio (UP) o Visión (MSF) y en la fase de Elaboración (UP) o Planeación (MSF). Por razones obvias, a medida que el proyecto avanza, tenemos menos tiempo para encontrar y documentar requisitos y es cuando más suposiciones se hacen sobre lo que ya está identificado.
  • Utilizamos herramientas de apoyo para la especificación y el modelado de requisitos, sobre todo herramientas que permitan realizar diagramas de casos de uso, diagramas de actividad, tableros de historias, simulaciones y prototipos, entre otros instrumentos de este tipo.
  • Hemos asistido a entrenamiento en los días previos al proyecto o hemos estado involucrados en proyectos problemáticos recientemente. Cuando esto ocurre, muy seguramente hemos estado sometidos a mucha presión y estrés, además de una limpieza de cerebro sin antecedentes y no queremos volver a equivocarnos.
  • Simplemente tenemos la experiencia suficiente y necesaria, hemos aprendido de nuestros aciertos y fallas del pasado y de las lecciones aprendidas en proyectos anteriores. Sin contar con que hemos consultado la gran cantidad de material que encontramos en este Gazafatonario IT sobre el tema.
Si algunas de o todas estas premisas no se cumplen, es muy probable que no sepamos cómo enfrentar los principales problemas en ese proceso espinoso que es la identificación de requisitos. Estos problemas se manifiestan de forma distinta:
  • Los usuarios no pueden o no saben describir muchas de sus tareas
  • Mucha información importante no llega a verbalizarse. Ocurre con frecuencia que de tanto ejecutar el proceso, este “desaparece”, se vuelve algo implícito y nadie es capaz de relatarlo.
  • En sistemas orientados a miles de usuarios, como los sistemas de la Web 2.0, a veces hay que “inventar” los requisitos. En estos casos, las suposiciones están a la orden del día y muchas de ellas nunca llegan a documentarse.
  • En general, la educción (extracción) de requisitos es un proceso pasivo, en el que el usuario espera del Analista Funcional la solicitud de conocer algo para él intentar entonces explicárselo de alguna manera.
Sobre este último síntoma, todo el proceso de identificación, clasificación, documentación y administración de requisitos de software debería ser un proceso cooperativo, que cuente con la participación del equipo técnico y de todos los interesados en el proyecto y en el producto y no solo de algunos pocos usuarios.

Finalmente, algunas técnicas bien conocidas y que son de utilidad al momento de encontrar requisitos y de las que hablaremos en otros artículos, son:
Preliminares:

Utilizar preguntas libres de contexto.

Tormenta de ideas:

Seleccionar un grupo variado de participantes.

Eliminar críticas, juicios y evaluaciones mientras los participantes sugieren ideas.

Producir muchas ideas.

Recogerlas todas por escrito.

Otro día, en otra sesión, se evalúan las ideas (se puntúan).

Elaboración de prototipos:

Útil cuando la incertidumbre es grande acerca del futuro sistema

Entrevistas:

Es el método “tradicional”,  pero debe usarse en complemento con otras técnicas, y no debe ser el primer paso de la educción. Es fundamental:

Entrevistar a la(s) persona(s) adecuadas.

Preparar las preguntas con antelación.

Utilizar diagramas, modelos, etc.

Observación y análisis de tareas:

Esta es una técnica tan antiquísima como la misma Ingeniería de Software. Un observador estudia a los futuros usuarios en su entorno de trabajo. A veces se utiliza el video. Anota todo aquello que es susceptible de mejora. Posteriormente, genera una serie de requisitos tentativos.

Casos de uso

Requisitos en contexto de uso. Sobre este asunto he expuesto docenas de artículos en este Blog.

Finalmente, recordemos que el objetivo de la Ingeniería de Requisitos es asegurar que se defina y desarrolle un producto efectivo de alta calidad desde el punto de vista de los interesados, así que si una especificación de requisitos de software incompleta es inevitable, definitivamente deberíamos aceptarla como completa haciendo suposiciones implícitas.