No conformarse

Uno de mis mejores compañeros y amigos se va de mi Cia. Es una de las personas más brillantes que he conocido jamás.

¿Porqué se va? Tiene un sueldo muy muy bueno, es una persona de referencia, disfruta de un área de confort de nivel, muy bien considerado por sus jefes, vía directa con la toma de decisiones, etc. 

Estoy seguro que el 90 % de las personas que trabajan con él no lo van a entender.

La razón..., no le dejan tiempo para pensar. No entiende como la primera empresa tecnológica de este país no tiene tiempo para pensar, cómo sus integrantes se han olvidado de lo que nos ha hecho fuertes, la innovación.

Este es el camino que estamos siguiendo, un camino que penaliza al que piensa y favorece la cuenta de resultados del corto plazo frente al largo plazo.

Seguiremos en contacto porque nos tenemos cariño pero me da una pena tremenda. Me perderé esas pequeñas charlas que nos damos y en las que intentamos encontrar soluciones a esto del software.

Me ha dejado un último consejo, una última perla: No te conformes!

Y eso es lo que voy a hacer, no conformarme. Voy a retomar mi trabajo en este blog como exploración y desarrollo intelectual de este tema que me apasiona, las metodologías.

Casos de Uso 2.0

No hace mucho, Ivar Jacobson, junto a Ian Spence y a Kurt Bittner, publicó el eBook "Use Case 2.0", sobre cómo mejorar el uso de los casos de uso.

Casos de Uso 2.0 se trata de una práctica para capturar requisitos y guiar la construcción del software.

Un caso de uso tiene una meta bien establecida, una estructura de historia entendida por todos los involucrados en el proyecto, pero también un conjunto de historias que el sistema debe satisfacer o cumplir, incluyendo la más simple, la cual es la historia más simple que le permite al usuario alcanzar la meta.

Todo esto se puede conseguir a partir del concepto que nos presenta Jacobson, la porción del caso de uso, que es una o más historias seleccionadas de un caso de uso para formar un elemento de trabajo que es de valor claro para el usuario. La porción actúa como un contenedor para todo el trabajo requerido para completar la implementación de las historias seleccionadas. Las porciones de casos de uso son más que requisitos y casos de prueba y evolucionan para incluir las porciones correspondientes a través del diseño, la implementación y las pruebas.

Las porciones de caso de uso: 

• Posibilitan que los casos de uso sean divididos en unidades de trabajo más pequeñas e independientemente entregables. 
• Posibilitan que los requisitos contenidos en un conjunto de casos de uso sean ordenados, priorizados y tratados en paralelo.
• Enlazan los distintos modelos de un sistema (requisitos,  análisis, diseño, implementación y pruebas) usados en el desarrollo dirigido por casos de uso.

Según Jacobson, la receta es sencilla: primero se identifica la función más útil que el sistema debe hacer y nos enfocamos en ello. Luego tomamos esa función más útil y la dividimos en porciones más pequeñas. Y después seleccionamos la porción más importante, una que "viaje" de principio a fin a través del proceso de desarrollo. Con el equipo de trabajo, estimamos el desarrollo y comenzamos a construir. Luego añadimos los casos de prueba previamente definidos para esa porción.

Ahora repetimos esto mismo mientras haya más porciones y más casos de uso que dividir. Así, el sistema lo vamos entregando por incrementos, "cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. 

Casos de Uso 2.0 es una práctica liviana, escalable, versátil y fácil de usar. El documento comienza presentando los principios básicos:

1. Mantenerlo simple contando historias

1. Entender el cuadro completo

1. Enfocarse en el valor

1. Construir el sistema por partes

1. Entregar el sistema en incrementos

1. Adaptarse para cubrir las necesidades del equipo.

Casos de Uso 2.0 es para todo tipo de sistemas; es para manejar todo tipo de requisitos,  incluyendo los no funcionales; puede aplicarse con cualquier estrategia de desarrollo o método; se puede escalar para cubrir todas nuestras necesidades en materia de desarrollo de software.

¿Demasiada documentación?

Si hacemos esta pregunta a casi todos los stakeholders de un proyecto seguro que nos contestan que sí, que hay demasiados entregables y que esto retrasa las fechas del proyecto. He dicho "a casi todos" porque seguro que al equipo de metodología del proyecto no le parecerán demasiados.
La realidad es que los entregables debe ser algo que debería fijar el propio cliente. Dentro de la ingeniería de Requisitos, los Requisitos Organizacionales forman parte de los Requisitos No Funcionales, y describen aspectos como:

• Procesos estándar utilizados.
• Fechas de entrega.
• Documentación a entregar. Una subcategoría definida como Requisitos de Entrega.
• etc.,.

Nosotros podemos (y debemos) ayudar al cliente a identificar sus necesidades, pero debemos llegar a un consenso en los entregables que debe recibir. Le debemos recordar que los entregables forman parte de su propia necesidad como dueño del producto software. No se hacen porque los desarrolladores quieran sino porque el cliente lo necesita como parte del producto.
Por supuesto, nuestra obligación también es intentar encontrar un nivel de documentación que no sea excesivo pero sí suficiente.

La documentación en el desarrollo de software

A menudo nos encontramos con los siguientes problemas:

• Falta de documentación.
• Exceso de documentación.
• La persona que ha escrito la documentación no está disponible.
• Contenido erróneo de documentación.
• Documentación desactualizada.
• La documentación no sigue el formato establecido según las normas de calidad.
• No contiene control de cambios.
• La documentación se contradice.
• No hay una norma establecida para la gestión de la documentación.
• La documentación no tiene las referencias ni fuentes que corresponden.
• Cada equipo de trabajo gestiona de forma diferente la documentación.
• La documentación fue elaborada con un software que ya no tenemos.

Debemos realizar una documentación de calidad. Debe ser un instrumento que sirva como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

La documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria.

Debemos distinguir entre varios tipos de documentación a la hora de elegir el tipo y la profundidad de la documentación:

• La documentación que se utiliza a lo largo del desarrollo del proyecto pero que no forma parte de la versión definitiva del producto software.
• La documentación que se utiliza como contrato con el cliente de lo que se va a realizar en el proyecto.
• La documentación que forma parte de los entregables del proyecto.

Respecto del formalismo en la documentación, aunque se puede ser flexible es importante que se siga homogeneidad. Se puede partir de un conjunto de plantillas estándar y negociarlas con el cliente con el fin de que se encuentre cómodo con lo que recibirá.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado.

Publicado con Blogsy

El IIBA y el Análisis de Negocio

Os describo qué es y para qué sirve el IIBA

IIBA y Análisis de Negocio

La comunidad internacional de profesionales que se dedican a la definición y especificación de requerimientos decidió crear el International Institute of Business Analysis (IIBA) con el fin de definir las mejores prácticas para esta función.

Gracias a esta organización, se definieron las etapas, tareas, entregables y técnicas necesarias para ejecutar esta función, las cuales al ser adoptadas por una organización y por los practicantes de análisis de negocios en la organización, se mejora sustancialmente el rendimento de esta función ya que su objetivo principal es asegurar que el producto resultado del proyecto, esté construido de acuerdo a los requerimientos de los usuarios, que esté construido de forma correcta y que satisface las necesidades de la organización.

Las organizaciones de alguna manera se han dado cuenta del problema e incluso han creado áreas dentro de la organización para cubrir esta función, las han llamado de diversas formas: Analistas de Sistemas, Business Partners, Business Representatives, Embajadores, Ingenieros de Procesos, Analistas de Negocios, Arquitectos de Negocios, etc., etc. etc., sin embargo no saben qué es lo que estas personas deben de saber para ejecutar la función, o cuales son las mejores prácticas que tanto la organización como los profesionales que ejecutan la función deben de incorporar para realizar esta tarea de manera eficiente.

El Análisis de Negocios es la visión ampliada de la recolección de requerimientos. Uno de sus principios básicos es cambiar la mentalidad del analista de negocios de que no es un “tomador de pedidos”, si no que se convierte en un profesional con los conocimientos (técnicos y de negocios) y competencias (técnicas) necesarias para entender problemas de negocios y proponer soluciones a estos problemas. Su función no es sólo proponer soluciones de TI, sino proponer la solución que requiere la organización haciendo uso de los recursos de la misma esto es, una solución puede abarcar tanto los sistemas de una organización como los procesos o la estructura organizacional. El Analista de Negocios es capaz de proponer soluciones en cualquiera de estos ejes dentro de una organización.

En concreto, el Análisis de Negocios es acerca de entender un problema de negocios, proponer alternativas de solución y definir el alcance de la solución seleccionada considerando todos los recursos de la organización.

Creo que esto es un paso más allá de lo que entendemos como Analistas Funcionales dentro de nuestra organización, pero ¿porqué no podemos conseguir que se dé ese paso?

IIBA, CBAP y BABOK

Podemos equiparar IIBA al PMI, la certificación CBAP a la PMP y el libro BABOK al PMBOK.

Métodos para Análisis Funcional

El objetivo del análisis funcional es describir las funcionalidades del sistema mediante modelos o documentos de análisis. Identifica las interacciones con elementos externos y documenta las estructuras de información necesarias para completar el sistema.

Su papel en el desarrollo de la aplicación es fundamental:

• Servirá de contrato con el cliente.
• Permitirá explicar a nuestros desarrolladores qué funcionalidades tendremos que implementar.
• Nos permitirá estimar el esfuerzo que tendremos que realizar para obtener la solución.
• Podremos plantear qué pruebas tendremos que hacer para comprobar que lo que hemos hecho es lo que el cliente quiere.
• Cuando se acabe el desarrollo nos servirá para garantizar que nuestros equipos de mantenimiento conozcan la funcionalidad de la aplicación, con lo que los evolutivos o correctivos no serán traumáticos.

Un aspecto muy importante y que no debemos olvidar es que aunque el Análisis Funcional es una fase dentro del ciclo de vida del desarrollo, el papel del analista no finaliza cuando acaba la fase de análisis y entrega los artefactos de análisis que ha realizado (p.ej.: el documento de Análisis Funcional). Todo lo contrario, a partir de ese momento su objetivo debe ser que todas las personas involucradas en el desarrollo entiendan e implementen las funcionalidades planteadas.

Normalmente utilizamos uno de los métodos más extendidos en la ingeniería del software para realizar el análisis funcional, los Casos de Uso. Intentaré clarificar una serie de aspectos fundamentales, apoyándonos en ejemplos reales de buenas prácticas.

Además, propondrés técnicas de análisis que seguro en algún momento nos pueden servir para explicar detalles de nuestra solución.

 Nuestra labor como analistas no es hacer unos casos de uso con mucha literatura y super bien estructurados que solo entendamos nosotros. Nuestro objetivo debe ser hacer casos de uso que entienda el cliente y que se ajusten a lo que quiere, que entienda el desarrollador y que le permita realizar su código, que nos sirvan para estimar y que nos sirva para certificar que el sistema cumple con lo que el cliente necesita.

Razones para usar el Modelo de Casos de Uso

Existe mucha controversia sobre el uso del Modelo de casos de uso como especificación funcional del desarrollo de una aplicación. A continuación daré una serie de razones para utilizarlo:

El usuario final aprueba el modelo de caso de uso para saber como va a actuar el sistema. Los usuarios potenciales utilizan el modelo de caso de uso para comprender mejor el sistema. El arquitecto de software utiliza el modelo de caso de uso para identificar la funcionalidad arquitectónicamente significativa. Los diseñadores utilizan el modelo de caso de uso para obtener una visión general del sistema. El gestor utiliza el modelo de caso de uso para planificar y hacer el seguimiento del modelado de caso de uso y también del diseño posterior. Las personas externas al proyecto pero dentro de la organización (ejecutivos, etc.), utilizan el modelo de caso de uso para obtener una perspectiva de lo que se ha llevado a cabo. Las personas revisan el modelo de caso de uso para proporcionar la información de retorno apropiada a los desarrolladores de forma regular. Los diseñadores utilizan el modelo de caso de uso como base para su trabajo. Los verificadores utilizan el modelo de caso de uso para planear las actividades de prueba (prueba de caso de uso y de integración) tan pronto como sea posible. Quienes desarrollarán la versión siguiente del sistema utilizan el modelo de caso de uso para comprender como funciona la versión existente. Los escritores de documentación utilizan los casos de uso como base para escribir los manuales de usuario del sistema.

 

Publicado con Blogsy