Ya va un rato que no publicaba, ahora sí que demasiadas semanas de caos, pero aquí está el siguiente post. Anteriormente fuimos platicamos de como ir entendiendo el requerimiento del proyecto, desde 30,000 pies, definiendo las Necesidades, luego desde 20,000 pies definiendo los objetivos, y finalmente desde 10,000 pies definiendo el alcance.

Ahora nos enfocaremos en esos 10,000 pies, en como definir ese alcance inicial, o Backlog del Proyecto, para que sea claro para el cliente y para el equipo lo que se va a desarrollar. Esto es especialmente importante en proyectos con alcance cerrado, donde se debe de incluir todo lo que se va a hacer, y cualquier cosa adicional se considerará fuera del alcance. Pero también aplica a proyectos con alcance abierto para poder comenzar el desarrollo.

La principal intención es que aprendas a definir un listado que sea lo suficientemente completo para aclarar el alcance, y poder hacer un estimado de las horas que necesitarán para ejecutarlo, pero sin tener que hacer una planeación completa del proyecto o tener que definir todo el proyecto a detalle. Es la manera de definir un alcance sin tener que ejecutar el proyecto.

2 tipos de Funcionalidades

Para definir el alcance necesitamos definir toda la funcionalidad que se va a desarrollar. La manera más fácil de hacerlo es simplificar dicha funcionalidad en una de dos categorías.

• Historias de Usuario
• Escenarios Automatizados o de Comunicación

Aunque parezca una sobre simplificación del desarrollo. Con segmentar la funcionalidad en una de estas 2 categorías, podrás crear un listado de todo lo que se debe de hacer. Recuerda que solo nos estamos enfocando en las cosas que el software tiene que hacer, no nos estamos metiendo en arquitectura ni en implementación, pero los tiempos que definas para cada funcionalidad dependen de tu experiencia en estos dos puntos.

Ahora. Entendamos cual es la diferencia entre Historias y Escenarios.

Historias de Usuario

El termino de Historias de Usuario es bastante común en el desarrollo de Software, seguramente lo has escuchado. Aunque no es exactamente lo mismo también se les conoce como Casos de Uso. El nombre no importa, el concepto es lo importante.

“Una Historia de Usuario captura un requerimiento de interacción de un usuario con el sistema.”

Esto es fácil de entender, la Historia de Usuario es un documento que debe de tener todas las reglas de una sola interacción de un Rol con el sistema. Recuerda, es necesario mencionar cual es el Rol que realizará la interacción, y que debe de enfocarse en una sola interacción. De esa manera empezamos a listar nuestras Historias por cada uno de los roles del sistema.

En Scrum, el formato estándar para una historia de usuario es:

Como [ROL], debo de poder realizar [FUNCIONALIDAD], para poder [VALOR].

Ejemplo:

Como VENDEDOR, debo de poder CAPTURAR LOS DATOS DE UN NUEVO CLIENTE, para poder COTIZARLE.

En este caso el ROL es “Vendedor”, la FUNCIOALIDAD es “capturar los datos de un nuevo cliente” y el VALOR es para poder hacerle una cotización. Ve como solo nos enfocamos en una funcionalidad, esta historia de usuario se trata de Crear el Cliente, no de hacer la cotización. Si te concentras en unidades específicas de funcionalidad es mucho más fácil entender a todo lo que hace falta, y para el usuario también es más fácil entender que cualquier unidad de interacción requeriría una nueva definición, un nuevo documento, y tiempo de desarrollo.

Como guía general para las interacciones con usuario, podemos usar el patrón usado por casi todos los generadores de Código. Listado, Creación, Edición, Detalle, Borrado/Desactivado. Utilizando este patrón como base para las interacciones podemos agilizar la definición de los requerimientos del sistema. Por ejemplo, un objetivo puede ser “Controlar los Clientes del Vendedor”, con esto en mente podemos plantear las siguientes historias:

• Listado: Como Ventas, debo de poder ver el listado de Clientes, para poder trabajar con ellos.
• Creación: Como Ventas, debo de poder capturar los datos de un nuevo cliente, para poderle vender.
• Edición: Como Ventas, debo de poder editar los datos de un cliente, para poder seguirle vendiendo.
• Detalle: Como ventas, debo de poder ver el detalle de un cliente, para confirmar que los datos están bien y ver sus últimas 5 ventas.
• Borrado/Desactivado: Como Ventas, debo de poder desactivar un cliente, para ya no venderle más.

Esto es un ejemplo simplificado, pero si empiezas en base a los objetivos, deberías de poder desglosar todo el sistema con escenarios relacionados. Por ejemplo, si el sistema es para vender, para vender necesitas tener clientes y productos, necesitas tener precios etc. Con cada elemento que detectas puedes comenzar a desglosarlo utilizando el mismo patrón.

Como tips adicionales:

• En Listados, es común funcionalidad adicional como un buscador simple, acomodo por columnas o paginado. Define un estándar de lo que incluye tu listado y si necesita funcionalidades adicionales ponlas en historias separadas.
• En mi caso casi siempre junto la historia de creación y edición en una misma, esto depende de la tecnología que estés usando y los patrones a los que estés acostumbrado.
• Las pantallas de detalle usualmente requieren solo poner los datos de la entidad, pero cuando la entidad tiene información relacionada, como las ventas del cliente, es necesario especificarlo. Si es funcionalidad adicional debe ser otra historia.
• Borrado y Desactivado lo considero lo mismo, porque en los sistemas de línea de negocio es muy raro que se permitan borrar datos de manera permanente.
• Con esté patrón es más que suficiente para definir casi cualquier interacción del usuario con el sistema. Si tus pantallas son más complejas, simplemente son una combinación de los 5 casos posibles.

Con esta idea, haz un listado de todas las Historias que tendrás por cada uno de los Roles del sistema. No hace falta hacer el documento a detalle, con el listado es suficiente. Si el cliente está pidiendo cosas que salen de un estándar, como reglas de negocios o requerimientos funcionales., recuerda incluirlas como subpuntos en el listado para recordad que se están considerando, y que hay que ajustar el cálculo de los tiempos acorde.

Recuerda que cualquier tipo de función que requiere hacer un “Administrador” del sistema, debe de ser incluida, en estas historias incluirás cosas como la administración de usuarios o cualquier pantalla utilizada para diagnóstico del sistema.

Escenarios de Automatización o Comunicación

La palabra “Escenarios” definitivamente no es un estándar como lo es “Historia de Usuario”, ahora sí que fue una palabra que yo escogí para definir toda funcionalidad que no requiere la interacción con un usuario.

“Escenario es toda funcionalidad que no requiere interacción con un usuario.”

Estos escenarios son mucho más importantes definirlos a detalle, ya que existe mucho más riesgo que en la ejecución de Historias de Usuario. Dentro de estos escenarios básicamente podemos dividir en:

Escenarios de Automatización

Este es cualquier escenario donde la aplicación debe de ejecutar alguna acción sin ninguna interacción. Casos comunes son consolidación de reportes, actividades de mantenimiento y limpieza, o procesamientos de mensajes por medio de colas.

Estos escenarios no suelen ser muy complicados. Usualmente funcionan por medio de un Trigger, una ejecución y una salida, pero es importante definirlos para no haya duda o expectativas diferentes de lo que va a pasar. En general la mejor práctica para definir estos escenarios es definir:

• Trigger: En base a que se va a detonar la ejecución de la funcionalidad. Está puede ser en base a una fecha u horario, o en basé a otra acción.
• Acción: Hay que ser muy claro en cual será la acción que se va a realizar. Reglas de negocio, origines de información, algoritmos, etc.
• Resultado o Salida: La salida que se espera del proceso automatizado.
• Tecnología: Es importante definir la tecnología a usar, está de manera independiente al resto de la tecnología utilizada para el proyecto. Esto porque usualmente estos procesos se ejecutan en aplicaciones adicionales o de externos.

Escenarios de Comunicación

Estos incluyen cualquier comunicación que se tenga que hacer desde el sistema desarrollado hacía afuera, o desde, otro sistema hacia el sistema desarrollado. Básicamente cualquier comunicación con otro sistema que no participa un usuario. Estos pueden ser APIs, Web Services, Sincronización, etc.

Este suele ser uno de los puntos más críticos de los proyectos de desarrollo, cuando se requiere conectar con otros sistemas externos, no controlados por nosotros. Es necesario tener claro cómo se realizará esa conexión. Necesitamos tener la información de que tipo de conexión se va a usar, si hay documentación, y si hay apoyo de alguna persona del otro sistema. Es imposible hacer la definición a detalle como parte del levantamiento, pero en general se pueden separar por su nivel de dificultad en:

• Fáciles
  • Se utiliza una tecnología estándar específica para comunicar dos sistemas. API (Json o XML) o Web Service SOAP.
  • Hay apoyo de alguien del otro sistema, que conoce y nos puede guiar en cómo hacer las conexiones, o hay suficiente documentación en Internet acerca del proceso de integración.
  • No se utiliza ningún tipo de conexión complicada, como tener que crear o solicitar certificados o llaves de cifrado en tiempo real.
• Intermedias
  • Cualquier cosa por conexión con archivos planos. En especial si se tienen que definir como parte del proceso.
  • Conexiones por medio de bases de datos intermedia. Donde ambos sistemas depositan y leen. Donde ya existe la Base de Datos y el proceso por parte del otro sistema, y hay apoyo de alguien que conozca dicha Base de Datos y te explique cómo integrar.
  • Cuando es por API o Web Service, pero no hay mucha documentación, pero hay, o no hay una persona del otro sistema que pueda apoyar de tiempo completo.
  • Cuando es por medio de API o Web Service, pero no existen y es parte del proyecto definir de los dos lados que se necesita. El proceso de definición toma tiempo, y se tiene que calcular.
• Difíciles
  • Cualquier tipo de conexión por medio de librerías .DLL o SDKs que no tengamos experiencia.
  • Cualquier tipo de conexión por archivos binarios (no de texto plano).
  • Cualquier tipo de conexión por base de datos intermedia, pero que no existe y hay que definirla como parte del proyecto.
  • Cuando es por API o Web Service, pero no hay documentación, o no hay una persona del otro sistema que pueda apoyar de tiempo completo.

Hay que tratar de aclarar en lo posible los puntos específicos de conexión, y de ser posible, con el proveedor del otro sistema. El punto es aclarar en manera de proceso:

Cuando pase [X], envió al otro sistema [Y], usando [Z]. O, cuando pase [X] en el otro sistema, el otro sistema nos envía [Y] por medio de [Z].

Define todos estos escenarios. Tener clara la cantidad de escenarios necesarios y su complejidad hace más fácil calcular las horas requeridas para su ejecución. Y recuerda aclarar que cualquier cambio puede tomar horas adicionales.

Como Tip adicional, hay que tener cuidado con:

• Muchas veces el cliente tiene un sistema, pero no tiene un proveedor o nadie que sepa de ese sistema, y cree que nosotros podemos conectarnos “mágicamente” a cualquier sistema. Si no hay apoyo de alguien del otro sistema, o no hay documentación extensa acerca de cómo hacerlo, lo más probable es que sea imposible. Cualquier caso de estos hay que evitarlo y comentarlo inmediatamente con el cliente. Si el cliente insiste hay que hacerle una propuesta por horas abierta para poder investigar las opciones, y siempre sin garantía.
• Cualquier caso de integración donde no hay otra persona, ni documentación amplia, clara y con ejemplos, de cómo conectarse al otro sistema. En estos casos es mejor evitar cualquier tipo de compromiso.

Alcance o Backlog Inicial

Listo, con esta guía puedes hacer el listado a detalle del alcance, o si estas en un esquema mas agile y por horas, tu Backlog.

En caso de un proyecto con alcance cerrado, puedes comenzar a calcular las horas que cada historia o escenario te toma en realiza, recordando que necesitas el tiempo del analista, diseñador, desarrolladore, Tester, etc. Es decir, todas las horas requeridas para hacer la tarea completa. Una vez que el cliente aprueba el alcance, puedes trabajar sobre él, si el cliente quiere algo que no estaba, tendrás que trabajarlo como una solicitud de cambio.

En el caso de Agile, no es necesario tener todas las historias, el chiste es acordar las Historias y Escenarios iniciales con el Product Owner para comenzar a trabajar. Hacerlo así siempre va a ser mucho más sano.

Resumen

Para poder definir el alcance de un proyecto, tenemos que hacer un listado de todas las Historias de Usuario y Escenarios de Automatización o de Comunicación que se necesitan desarrollar. Con esté listado es mucho más fácil comenzar a hacer un estimado de horas, y a partir de este, una cotización.

En el caso de Agile, y en un proyecto por consumo de horas, puedes utilizar la misma guía para crear tu Backlog inicial y comenzar a trabajar.

Recuerda:

• Toda la funcionalidad del sistema la puedes separar en Historias de Usuario, o Escenarios de Automatización y Comunicación.
• Las Historias son cualquier interacción que debe de poder tener un ROL (usuario) con el sistema.
• Las Historias deben de seguir el formato. Como [ROL], debo de poder [FUNCIONALIDAD], para [VALOR].
• Puedes usar el patrón Listado, Creación, Edición, Detalle, Borrado como guía para empezar a hacer tus historias.
• Los Escenarios son cualquier funcionalidad que requiere el sistema, pero no hay interacción con usuarios. Se dividen en Automatización y Comunicación.
• Los Escenarios de Automatización son cosas que debe hacer el sistema de manera automática en base a una Trigger. Es necesario que definas el Trigger, la Funcionalidad a Ejecutar, la Respuesta o Output y la Tecnología a usar.
• Los Escenarios de Comunicación son cualquier comunicación que requiere el sistema con otro sistema externo. Aquí es importante medir la dificultad en base a la tecnología y cuando soporte o apoyo existe por el proveedor del otro sistema, y documentar todos los escenarios con el estándar: Cuando pase [X], envió al otro sistema [Y], usando [Z]. O, cuando pase [X] en el otro sistema, el otro sistema nos envía [Y] por medio de [Z].