Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Analista de Negocio. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Analista de Negocio. Mostrar todas las entradas

lunes, junio 02, 2014

Libro: Asuntos de la Ingeniería del Software- volumen II

Portada del libro
Portada del libro
Este no es el primer libro sobre temas de la Ingeniería de Software y está lejos de ser el último; acaso sea el primero en español escrito sobre las bases de nuestra propia práctica de campo, en nuestra propia economía, con nuestra propia idiosincrasia, aunque con el suficiente equipaje teórico proveniente de la academia y de los expertos en los temas citados.
Escribí el libro originalmente como una serie de artículos en mi Gazafatonario IT y cada artículo siempre tuvo su fuente precisamente en tres aspectos primordiales: la industria del software (y por Industria quiero decir Intergrupo), la academia (léase la Universidad) y los especialistas en distintas áreas de la ingeniería de software.
El libro cubre algunos de los temas fundamentales que sirven de base al trabajo diario de los profesionales del software y que son de vital importancia para los desarrolladores actuales: el lenguaje de modelado unificado o UML, los procesos de software, la orientación a objetos y la ingeniería de requisitos con casos de uso, principalmente.
Los conceptos de ingeniería provienen necesariamente de la teoría formal de los lenguajes de modelado de sistemas, las técnicas orientadas a objetos de modelado de software, los métodos de construcción de software y la identificación, especificación y administración de requisitos de software con casos de uso, entre algunos otros. Desarrollé esos conceptos a través de cada capítulo en un estilo riguroso pero informal, más bien práctico, siempre pensando en poner de manifiesto lo que me ha funcionado a mí y a mis colegas, principalmente de Intergrupo, pero también de otras compañías del medio.
Parte 1 – Algunos Aspectos Esenciales de la Ingeniería de Software
El libro está dividido en dos secciones mayores. La primera parte del libro la dedico a explicar algunos de los asuntos que acusan recibo en la comunidad de ingenieros de software: UML, la notación estándar para modelar sistemas de software y otros sistemas que no son software; En lo que se constituye como los prolegómenos del libro, de manera sucinta describo la gran mayoría de los diagramas del lenguaje, con ejemplos breves pero suficientemente explicativos y desmitifico algunas de las creencias sobre la herramienta.
En el capítulo 2, hago una presentación general de los procesos de software y de cómo estos son usados por los practicantes de la industria, es decir, nosotros. Aquí empiezo a develar las prácticas más recurrentes para adoptar y adaptar procesos de software en una organización, tal y como lo hicimos en Intergrupo en una serie de incrementos que llevaron a convertirnos en una compañía CMMI nivel 5.
En los capítulos 3, 4 y 5 del libro, hago una vasta exposición del Proceso Unificado de Software, desde su marco general en el capítulo 3, hasta los detalles de la fase de Inicio o Concepción en los capítulos 4 y 5. En el primero de los apartados presento los conceptos inherentes al proceso y sus características: las fases y las disciplinas, las iteraciones, los roles y responsabilidades, las actividades y los artefactos. En los dos capítulos restantes, ya con miras a la segunda parte del libro, hablo profusamente de la etapa de inicio del proceso, sus principales hitos y el resultado esperado. Es aquí donde comienzo a hablar de la disciplina de ingeniería de requisitos y de casos de uso, asuntos que ocupan toda la segunda sección del libro.
Luego, en el capítulo 6, concluyo este primer segmento del libro con un tema que verdaderamente me apasiona, la orientación a objetos. Tardé muchos años en encontrar el enfoque justo para esta pieza, teórico-práctico, pero actualizado a las necesidades incesantes de los desarrolladores profesionales de este siglo 21. El capítulo contiene una serie extensa de conceptos aplicables al análisis, diseño y desarrollo de sistemas de software, incluso me atrevo a hacer una analogía en lo que he dado en llamar la Biología Informática, para que todos entendamos mejor y de una vez por todas y para siempre lo que es una clase (objetualmente hablando) y su enorme utilidad durante el ciclo de vida de construcción de software. Sobre objetos, siempre recuerdo lo que decía Edward Yourdon sobre ello: “las metodologías de la ingeniería de software orientada a objetos son la cosa más grande desde el pan tajado. En términos relacionados con computación, las técnicas orientadas a objetos son el desarrollo más importante desde la invención de las técnicas estructuradas durante las décadas de 1970 y 1980.”[1] Hoy lo siguen siendo.
Parte 2 – Ingeniería de Requisitos con Casos de Uso: Volumen 1
La segunda parte está dedicada completamente al asunto de los casos de uso como mecanismo de primera categoría para identificar, capturar, organizar, documentar y gestionar requisitos de sistemas de software. En el capítulo 7 hago una presentación concisa del tema, defino qué es un caso de uso y además establezco las diferencias sutiles que existen con los escenarios de uso de un sistema; también explico de qué se tratan los así llamados casos de uso esenciales como noción capital en la especificación de requisitos y también los distingo de los casos de uso descompuestos funcionalmente. El capítulo finaliza con el ejemplo de caso de uso más simple de todo, el caso de uso “¡Hola, Mundo!”.
En el capítulo 8 abordo el tema de los casos de uso del negocio y sus actores del negocio relacionados. También hablo de la fuente de los casos de uso, de donde provienen y hacia donde van a lo largo del ciclo de vida del software, para terminar con un ejemplo del cual luego hago un análisis exhaustivo.
En el capítulo 9 hago una descomposición de la estructura de un caso de uso y exhibo cada una de sus partes principales: la descripción breve, las precondiciones y poscondiciones del caso de uso, la secuencia básica y las alternativas y los requisitos especiales. Ya en los capítulos previos había tratado el tema del nombre y el actor del caso de uso.
Más adelante, en el capítulo 10, bajo el manto de un ejemplo representativo, enuncio mi Ley de la Terminación de un Caso de Uso, que me sirve para explicar uno por uno los puntos de una lista de verificación para saber si un caso de uso cuenta con los atributos mínimos requeridos para ser considerado un buen caso de uso. Las listas de verificación deben verse como instrumentos o herramientas de apoyo en el proceso de administración de la calidad de los productos que construimos, nunca como un documento que se debe “diligenciar”. También sirven para disminuir el nivel de subjetividad con que se revisa un producto de software o parte de este, o un artefacto relacionado con el software. Al menos, este es el mensaje que llevo implícito en esta sección del libro.
El capítulo 10 sirve como entrada al tema que abordo en el capítulo 11, este del análisis y diseño de los casos de uso, mejor conocido en el ámbito de los diseñadores de software como realización de casos de uso. Aquí evidencio la necesidad de contar con el conocimiento de conceptos tan importantes como las técnicas orientadas a objeto, que trato al final de la primera parte del libro, y donde hago un uso extenso del lenguaje de modelado unificado que trato en detalle en los prolegómenos del libro (capítulo 1). En este capítulo empiezo con una disertación sobre los problemas de comunicación existentes entre los miembros de un equipo de desarrollo de software y que son inherentes a la naturaleza humana. A continuación, con un ejemplo característico y práctico, hago una exposición detallada de los diagramas de interacción de UML, en general, y de los diagramas de secuencia, en particular, que sirven como mecanismos fundamentales para llevar a cabo estas realizaciones de casos de uso.
En el capítulo 12 cierro uno de los ciclos del libro sobre modelado de casos de uso y presento el no menos espinoso asunto de las relaciones entre actores y casos de uso y entre casos de uso. La generalización entre actores, una práctica poco usada entre los analistas de software, o muchas veces mal usadas, inicia este apartado. Luego continúo con la típica relación de inclusión de casos de uso, donde hablo de factorización de requisitos y de reusabilidad de requisitos; más adelante hago una disertación sobre la relación de extensión y sus diferencias principales con la anterior. Al final también hablo de la generalización entre casos de uso, aunque no la recomiendo mucho. Este capítulo aporta el enfoque sistémico de toda la segunda parte del libro y hace énfasis en cuando debemos usar una u otra relación, o todas ellas.
El capítulo 13 entra en el terreno de las buenas prácticas mostrando los errores más comunes que se cometen a la hora de usar casos de uso, algo que he dado en llamar “los casos de abuso”, es un juego de palabras pero ilustra a la perfección el punto al que quiero llegar. Enumero y explico una serie de dieciséis casos frecuentes de mal uso de los casos de uso, desde la mala práctica de usarlos en todo momento y en cualquier contexto, pasando por los errores habituales de documentar detalles técnicos o de la interfaz de usuario en el caso de uso, hasta la costumbre perfeccionista de solo presentar el caso de uso cuando está “felizmente” terminado, solo cuando contiene todos los detalles que se han acordado con el usuario. ¿Quién diría que lo perfecto siempre es mejor que lo bueno? Pues bien, aquí sucede exactamente lo contrario: lo acabado, lo ideal, lo absoluto es enemigo acérrimo de lo bueno, de lo que proporciona valor. Es una de las conclusiones que obtendremos al final del capítulo. Incluso muchos de nosotros hemos llegado a pensar que el analista de requisitos y otros miembros del equipo de desarrollo son síquicos y que pueden leer nuestros pensamientos y saber lo que queremos sin habérselos dicho. De todo esto se trata este estudio al que clasifico de patológico y de forense, fueron situaciones que discutí mucho con algunos de mis colegas en Intergrupo.
El último capítulo del libro fue otro de los que siempre quise escribir en mi Gazafatonario: se trata de diez más uno consejos útiles y simples para escribir efectivamente casos de uso efectivos. La aliteración en el título me sirve para abordar dos asuntos importantes: el problema de la comunicación efectiva entre las personas y el problema de la calidad y utilidad de los artefactos de software, en este caso, de los casos de uso. Me parecía razonable, después de la descripción sintomática que hago en el capítulo anterior, sobre los errores más pronunciados que cometemos a la hora de modelar sistemas de software con casos de uso, traerles algunas propuestas para remediar nuestro trabajo, hacerlo más productivo y de mejor calidad. De eso se tratan estos consejos.
Dónde conseguir el libro
El libro lo pueden conseguir en:



[1] Yourdon, Edward. Object-Oriented System Design, an integrated approach. Prentice Hall. 1994.

domingo, agosto 04, 2013

Historias de Usuario Altamente Efectivas, 2

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

INVEST es un acrónimo acuñado por Bill Wake para referirse a ciertas propiedades que debería tener una buena historia de usuario:


- Independiente
- Negociable
- Valiosa
- Estimable
- Sucinta

- cerTificable

Una presentación previa de este tema la hice en:
Cualidad :: Independiente
Para entender mejor este rasgo de las historias de usuario, veamos un par de historias dependientes entre sí:
Historia Dependiente 1
Como: Editor
Quiero: establecer las reglas de seguridad de la contraseña de los blogueros
Para: que los blogueros se obliguen a crear y retener contraseñas seguras, manteniendo seguro el sistema.
Historia Dependiente 2
Como: Bloguero
Quiero: Seguir las reglas de seguridad de las contraseñas establecidas por el Editor
Para: que mi cuenta se mantenga bastante segura.
A todas luces es evidente que completar la historia del Editor no deja el producto en un estado de potencialmente distribuible, por lo tanto, no tiene valor o no es valiosa por sí sola para el negocio. Esto ocurre porque la historia del Editor solo es verificable en cuanto a establecer, eliminar y preservar la política, pero no es verificable cuando de hacerla cumplir al bloguero. Reconsiderando las historias y el diseño del sistema, podemos eliminar la dependencia dividiendo las historias de una manera diferente, en este caso, a través de los tipos de políticas de seguridad aplicadas y combinando la configuración de la política con normas para hacerlas cumplir en cada historia:
Historia independiente 1
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.
Historia Independiente 2
Como: Editor
Quiero: establecer las características de solidez de la contraseña
Para: que los blogueros deban crear contraseñas difíciles de jaquear o de descifrar.
Ambas historias están escritas desde el punto de vista del Editor. Esto es así porque los blogueros simplemente “usan” o “consumen” las restricciones impuestas por el Editor. En el segundo ejemplo, cada historia puede valerse (y valorarse) por sí misma y puede desarrollarse, verificarse y entregarse independientemente. Una buena práctica es preguntarnos para cada Historia de Usuario si hemos hecho todo lo posible para que esta sea independiente del resto. La independencia permite además construir la historia, es decir, convertirla en software funcionando, en iteraciones diferentes o aun en entregas distintas del mismo proyecto.
Ahora bien, la dependencia entre historias de usuario se presenta de distintas formas. Bill Wake, el creador del modelo INVEST, describe4 tres tipos comunes de dependencia: de Superposición, de Orden y de Contención.
Dependencia por Superposición de Funciones
El primero de estos casos es el más doloroso de todos. El siguiente par de historias nos muestran esta situación:
Figura 1: Historias dependientes por superposición de funciones
Figura 1: Historias dependientes por superposición de funciones (Haga clic sobre la imagen para ampliarla)
Observemos la actividad (el “Quiero”) de estas historias. La conjunción “Y” presente en cada una de ellas ya hace que estas historias sean “sospechosas”. Por supuesto, la superposición se da entre dos o más historias y lo que procede es tratar de reducir o de eliminar la trasposición de funciones. En el caso actual podemos convertir estas dos historias en tres, teniendo en cuenta que “Agregar comentarios a las entradas” se repite en ambas historias:
Figura 2: Historias independientes luego de remover la superposición de funciones
Figura 2: Historias independientes luego de remover la superposición de funciones (Haga clic sobre la imagen para ampliarla)
Como siempre debe ocurrir con las historias de usuario, las estamos viendo desde el punto de vista del usuario, no de lo que tenemos que hacer para implementarla. En este sentido, seguramente parte de la funcionalidad de agregar comentarios, sino toda, se comparte con la de Responder a Comentarios, pero eso es un asunto técnico que poco o nada interesa a quien usará las funcionalidades una vez estén expuestas. No se trata de interposición técnica, sino funcional.
Dependencia por Orden de Funciones
Esta es quizás la dependencia a la que estamos más atentos. Se trata de esas funciones de la solución que se deben implementar antes que otras. Pero también son dependencias fáciles de remover cuando se presentan. Por ejemplo, para agregar o responder a comentarios a las entradas, el lector del blog debe identificarse primero y para ello debe registrarse primero. Es la secuencia del proceso de negocio y, por consiguiente, funcional. Estas historias pueden lucir como se muestra en la figura a continuación:
Figura 3: Historias dependientes por orden de funciones
Figura 3: Historias dependientes por orden de funciones (Haga clic sobre la imagen para ampliarla)
En principio, el registro (registrarse) puede evitarse matriculando “a mano” las primeras cuentas para que el sistema comience a funcionar o, incluso, se puede usar la funcionalidad de Ingresar al Blog para hacer el registro sin que el usuario esté consciente de ello. Pero Ingresar al Blog también se puede dejar para después de Agregar Comentarios y realizar una entrega de la solución donde los lectores puedan adicionar comentarios sin tener que identificarse. Como siempre lo que prima es implementar primero lo de mayor valor para el negocio (para el Dueño del Producto) y lo de mayor riesgo. En este caso, con la historia Agregar Comentarios se logran ambos cometidos.
Dependencia por Contención
Se trata de esas historias que hacen parte de otra, llamadas así sub-historias o algo por el estilo. La confusión se hace latente cuando decidimos aceptar la jerarquía típica de las historias en Épicas y Temas, que son técnicas para describir un sistema de software. Pero dejando de lado esa clasificación, lo que debemos tener en cuenta es que la ordenación o estructura de un sistema casi nunca coincide con la agenda de su implementación. Pensemos por ejemplo en la historia Ingresar al Blog de la sección anterior.
Esta historia podría incluir una funcionalidad para recordar el nombre de usuario al lector del blog o una para restablecer la contraseña si está se ha olvidado, o ambas. Decimos que estas dos funcionalidades adicionales están contenidas en la funcionalidad de la historia Ingresar al Blog que se transforma así en una épica. La carta de intención de estas historias podría lucir como en la siguiente figura:
Figura 4: Historias dependientes por contención de funciones
Figura 4: Historias dependientes por contención de funciones (Haga clic sobre la imagen para ampliarla)
Lo que puede ocurrir al implementar la historia Ingresar al Blog como un todo es que hayan dos enlaces rotos en la funcionalidad (“Restablecer contraseña” y “Recordar usuario”) hasta tanto estas dos últimas historias no se implementen. Y si esto no se logra durante la misma iteración (Sprint) entonces no tendríamos un incremento del software funcionando potencialmente distribuible, al menos, no uno completo.
En cambio, si tratamos estas historias como totalmente independientes y los enlaces “Restablecer contraseña” y “Recordar usuario” los tratamos en cada historia respectiva, al terminar de implementar la historia Ingresar al Blog sí tendremos un incremento funcional distribuible. Otra vez, el valor para el negocio y el riesgo son dos aspectos muy importantes a tener en cuenta a la hora de tomar una decisión sobre cual historia implementar primero y cual historia construir después. En este caso, el tamaño (cualidad que abordaré en otra sección), también juega un papel significativo.
Comentarios Finales
Aplicar el modelo INVEST a cada historia de usuario es una tarea compleja y lleva tiempo lograr los resultados que queremos. En particular, lograr que todas las historias sean independientes es una labor colosal que puede retrasar el proyecto innecesariamente si no tenemos la experiencia suficiente. Contar con un equipo multidisciplinario, maduro y conocedor profundo de estos atributos ayuda. De lo contrario, la I de INVEST no será por Independiente sino por Imposible. La buena noticia es que no tenemos que hacerlo todo de una vez. Como siempre, aplicamos el enfoque iterativo y a medida que refinamos el Backlog del producto, podemos tratar los asuntos de dependencia entre una historia y otra.
Hasta aquí mi enfoque sobre la independencia en las buenas historias de usuario. En la próxima entrada abordaré el no menos espinoso asunto de la Negociabilidad de las historias de usuario.
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:
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:
Referencias
  1. INVEST in Good Stories, and SMART Tasks: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
  2. A User Story Primer, by Dean Leffingwell with Pete Behrens
  3. User Stories Applied, by Mike Cohn
  4. Independent Stories in the INVEST Model: http://xp123.com/articles/independent-stories-in-the-invest-model/



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!

domingo, octubre 07, 2012

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.

domingo, abril 15, 2012

Todavía Otro Cuerpo de Conocimiento Más (BABOK 2.0)

El Business Analysis Body of Knowledge (BABOK) es una colección de conocimiento dentro de la profesión del Análisis de Negocio y refleja unas mejores prácticas generalmente aceptadas. Como con otras profesiones, el cuerpo de conocimiento es definido y mejorado por profesionales Analistas de Negocios quienes lo aplican en su trabajo diario. El BABOK  describe las áreas de conocimiento del Análisis de Negocio, sus actividades asociadas y las tareas y habilidades necesarias para ser efectivo en su ejecución.
Como todo cuerpo de conocimiento (PMBOK, SWEBOK, entre otros), el BABOK tiene varias áreas de Conocimiento. Cada una de estas áreas se enfoca en una parte del análisis del negocio. Estas áreas son:
·         Planeación y Monitoreo del Análisis de Negocio
·         Obtención de Requisitos
·         Gestión y Comunicación de Requisitos
·         Análisis Empresarial
·         Análisis de Requisitos
·         Evaluación y Validación de la Solución
·         Competencias Subyacentes 
·         Dinámica de Análisis de Negocios 
Me parece importante anotar que esto no es más que eso, una propuesta de prácticas que funcionan en ciertos contextos, en muchos realmente, pero no es una solución definitiva a todos los posibles escenarios que nos encontramos en la “vida real” del análisis y modelado de negocios en los proyectos actuales.
Cuando se trata de estándares siempre recomiendo darles el beneficio de la duda. Lo primero que debemos hacer es estudiarlo profusamente y entenderlo, apoyándonos en expertos que lo hayan puesto en prácticas en diversas situaciones. A partir de allí, podemos iniciar un proceso de adopción y adaptación. A esto último yo lo llamo “tropicalización”.
Lo adaptamos a nuestras necesidades, a nuestra forma de hacer las cosas, a nuestro presupuesto y economía, a nuestra experiencia (que siempre nos va a faltar), a nuestra idiosincrasia, a nuestra forma de ver el mundo y de interpretarlo, a la agenda tan apretada que tenemos en los proyectos. Esto es importante, porque este tipo de estándares son definidos por organizaciones o grupos de organizaciones que tienen otra filosofía, existen en otras economías (generalmente mejores que las nuestras), la gente que los práctica allá piensa diferente, los proyectos tienen otros presupuestos y otras agendas, los equipos de trabajo son más grandes, tienen más recursos y más experiencia, tienen más expertos, etc.
¿A quiénes les interesa este estándar?
Principalmente a los Analistas del Negocio, pero también a los Ingenieros de Requisitos o Analistas de Requisitos.
“El Analista de Negocios es el responsable de identificar las necesidades de negocios de sus clientes y usuarios interesándose en ayudarlos a determinar las soluciones a sus problemas”.
·         El Analista de Negocios es responsable del:
o    Desarrollo y Administración de Requisitos de sistemas
o    Validación de requisitos para re-ingeniería de Procesos
o    Análisis y recomendación de soluciones de mejora continua
o    Validación y documentación de problemas y oportunidades de negocio
o    Análisis de requisitos Organizacionales u Operacionales
·         Las Soluciones NO son predeterminadas por el Analista- de Negocios- y son manejadas solamente a través del requerimiento de negocios.
·         Las Soluciones frecuentemente incluyen componentes de desarrollo de sistemas- pero pueden también consistir en mejoramiento de procesos o cambios organizacionales.
·         El Analista de Negocios es el facilitador clave dentro de una organización, el cual actúa como puente entre el cliente, el usuario interesado y el equipo de solución.
·         El Análisis de Negocios es distinto al análisis financiero, a la administración de proyectos, al aseguramiento de calidad, al desarrollo organizacional, a la ejecución de pruebas, a la capacitación y al desarrollo de documentación.
Sin embargo dependiendo de la organización, un Analista de Negocios puede ejecutar alguna o todas estas funciones relacionadas.
Estándares Relacionados
Relacionado estrechamente con el BABOK encontramos el SWEBOK (Software Engineering Book of Knowledge), sobre todo en el capítulo 2 que tiene que ver con Ingeniería de Requisitos. Este estándar es soportado por la IEEE.