miércoles, 31 de octubre de 2012

Toma de Requisitos - Paso 2: Entrevistas



Reuniones según Dilbert

Esta entrada forma parte de una serie cuyo índice es el siguiente:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Para poder identificar los requisitos preliminares, es habitual llevar a cabo entrevistas (reuniones) con los usuarios clave, principalmente. A partir de los requisitos que se identifiquen, se creará posteriormente un prototipo que permita identificar la interfaz de usuario, y el flujo de la aplicación.

Steve McConnell, en su "Software Project Survival Guide" ya avisa de que los programadores, la gente que nos dedicamos al desarrollo de software, no somos buenos diseñando software que realmente guste a los usuarios. La buena noticia, es que sí que podemos ayudar a los usuarios clave a descubrir lo que les gusta, gracias a que los propios usuarios tampoco suelen ser buenos diseñando software.

Cómo preparar las entrevistas: Fases

Fase 1: Preparación previa.
  • Fijar objetivos
  • Seleccionar los asistentes (en realidad esto ya lo hemos hecho en el paso anterior de la toma de requisitos: seleccionar a los usuarios clave).
  • Acordar con los asistentes el día, hora, lugar y duración de la reunión, al menos inicialmente.
  • Hacer los deberes: obtener información previa de los usuarios clave que van a asistir, sus necesidades, su negocio, las aplicaciones o productos que utilizan, los proveedores de servicios actuales...vamos, auténtica labor de detective.
Fase 2: Planificación.
  • Preparar un orden del día, así como los materiales necesarios.
  • Comunicar el orden del día a los asistentes
  • Enviar la convocatoria de la reunión a los asistentes, gestionando las confirmaciones, de forma que se replanifique la fecha, hora o lugar si es necesario.
  • Crear expectativas. Esta es la parte más delicada: es posible manejar las expectativas de los usuarios clave desde antes de la propia entrevista de recogida de requisitos.
Fase 3: Ejecución
  • Hacer preguntas claras. Honestidad y sinceridad. Queremos solucionar los problemas del cliente.
  • No debemos obsesionarnos con la tecnología.
  • No debemos obsesionarnos con el cómo ni el cuándo, sino con el qué. Debemos aclarar qué necesita.
  • Humildad. Solemos intentar proponer sistemas maravillosos cuando en realidad el cliente ya tiene sistemas muy buenos que cubren un porcentaje grande de sus necesidades. Es importante empezar aprendiendo (además del trabajo previo que ya deberíamos haber hecho) de qué y cómo se hace actualmente.
  • Una vez aclarado el qué, podemos pasar al cómo, pero siempre a nivel funcional, sin tecnicismos.
  • Es importante usar un lenguaje no técnico, o en todo caso, hablar en el lenguaje de su profesión o negocio, no en el nuestro. Pocas cosas hay tan irritantes como un joven friki sacando constantemente temas técnicos que no vienen a cuento.
  • Limitar lo que pide el cliente o usuario clave.
  • Detectar dependencias con temas que ya hayan comunicado otros usuarios clave, y anotar todo lo que se diga, ya que pueden ser pistas para lo que se trate en próximas entrevistas con otros usuarios.
  • Paciencia y respeto.
  • Anotar todos los detalles.
  • Los plazos no son importantes aún: no está definido el alcance, ni cómo vamos a implementarlo, por lo que los plazos no deben ser un bloqueo.
  • No adelantar la solución técnica. No matemos a la gallina sin haber empollado aún el huevo.
Fase 4: Revisión
  • En esta fase la temática es simple: revisar todo lo que hayamos anotado y asegurarnos de que incluso lo no anotado en la reunión, se registra y no se pierde.
Fase 5: Consolidación
  • Una vez que tenemos la documentación de la entrevista, habrá que consolidarla. Reducirla. Quitar lo redundante, lo que ya se haya obtenido en otras entrevistas. Quitar lo que corresponda a otras entrevistas (con otros usuarios clave), y completar su documentación allí.
  • Revisar otras entrevistas, y actualizar las dependencias entre los resultados de las distintas entrevistas. 

Problemas habituales en las entrevistas de toma de requisitos

  • No se entiende lo que se pide.
  • Se tiende a dar una solución inmediata, en la mayoría de las ocasiones una solución técnica conocida, sin esperar a asegurarse de que realmente el requisito ha sido entendido.
  • Se pierden en los detalles.
  • Mayor preocupación por los plazos que por los objetivos funcionales.
  • Enfasis en la tecnología, perdiendo de vista los requisitos.
  • Desconocimiento de la terminología del cliente.
  • Falta de paciencia. Los usuarios saben lo que quieren y hay que ayudales a expresarlo. Por sí solos, es difícil que sepan expresar todo lo que necesitan de un producto.
  • Hay dependencias. Raro es que una sola persona tenga toda la información. Lo normal es que tras cada reunión, se solventen dudas que habían aparecido en reuniones anteriores con otros usuarios clave, y surjan nuevas dudas que se resolverán en entrevistas posteriores.
  • Falta de limitaciones. Los usuarios no tienen límite a la hora de pedir. Y esto es un arma de doble filo: si les bloqueamos muy pronto, obtendremos usuarios insatisfechos. Si tardamos mucho, es posible que los requisitos sean difíciles de cumplir, complejos, oscuros.
Volver al Índice de pasos para la Toma de Requisitos.

domingo, 21 de octubre de 2012

Toma de Requisitos - Paso 1: Usuarios clave


Los usarios clave deben aportar valor
Los usuarios clave nos van a permitir definir los requisitos principales del producto, y nos van a guiar en las fases posteriores.




Esta entrada forma parte de una serie cuyo índice es el siguiente:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Éstos usuarios deben seleccionarse de forma que sean:
  • Abiertos
  • Capaces de aportar
  • Conocedores del negocio
  • Involucrados en la solución
  • Sin motivaciones ocultas
  • Variados funcionalmente

Abiertos

Deben ser abiertos, para que estén dispuestos a contar libremente lo que necesitan. Deben estar abiertos a dar sus necesidades actuales, abiertos a incorporar en su negocio las posibilidades tecnológicas.

Capaces de aportar

Han de ser capaces de aportar, de expresar lo que necesitan. Un usuario puede ser conocedor del negocio y abierto, pero si no es capaz de expresar lo que quiere...tenemos un problema.

Conocedores del negocio

El motivo de ser conocedores del negocio, está claro: han de aportar las cosas de forma que si un usuario clave dice que una característica es necesaria, o que debe cumplirse de una forma específica, sepamos que lo que dice es importante, y que realmente es necesario. Al contrario, si un usuario clave te dice claramente que algo puede no implementarse, y que dicha característica no es necesaria, créeme que es mejor que la quites, y que la quites ya.

Involucrados

La involucración es fundamental. Los usuarios clave han de estar dispuestos a dar su tiempo. Y nosotros debemos respetar ese tiempo, valorarlo, agradecerlo, y demostrarlo.

Motivados

El tema de la motivación es complejo. Muchas veces, a pesar de concurrir todas y cada una de las características anteriores, un usuario tiene motivaciones ocultas. Si es así, y dichas motivaciones no están alineadas con el negocio corporativo, es posible que surjan aplicaciones con funcionalidades contradictorias, o que sin tener apariencia contradictoria, hagan que su uso no sea consistente. Las motivaciones ocultas las he visto siempre más orientadas a las luchas internas de poder en las empresas, entre departamentos o áreas de negocio. Pero pueden producirse otros casos similares, y hay que vigilarlos.

Variados funcionalmente

¿A qué me refiero con variados funcionalmente? Pues que los usuarios clave deben abarcar el conocimiento de toda la funcionalidad del sistema a construir. Esto es muy fácil de decir, porque hasta que no esté construido el sistema, y se pruebe que es el adecuado, no sabremos quién tenía el conocimiento. Aquí de nuevo, entra la experiencia: lo obvio son las áreas funcionales del tipo "compras", "ventas", "almacén", etc. Donde ya no es tan obvio es en la definición de interacciones (requisitos de interfaz), u otros requisitos no funcionales.

En proyectos internos, es posible que los responsables recluten y proporcionen usuarios reales que estén involucrados en el proyecto y quieran dar sus visiones. Pero en proyectos llave en mano, o  externos, también es posible utilizar estas técnicas.

En cualquier caso, es importante planificar y estructurar adecuadamente el tiempo que dedican los usuarios clave. Esto lo veremos más adelante, en los pasos siguientes de la toma de requisitos.

Volver al Índice de pasos para la Toma de Requisitos.

viernes, 19 de octubre de 2012

Kanban Avanzado

Hoy os voy a dejar un regalo especial. Tengo el placer de leer de vez en cuando un blog muy interesante, y hoy veo que hoy merece la pena simplemente enlazar unos cuantos posts de lo que yo llamaría "Kanban Avanzado".

La autora, Teodora Bozheva, nos deja unas cuantas perlas. Que las disfrutéis:

Primeros pasos: Kanban en organización tradicional
Kanban para la gestión del portfolio de proyectos.
Si no lo ves, no lo puedes controlar (Gestión Kanban)
Kanban: una solución para la crisis.

Teodora, y ahora...¿qué puedo hacer yo para superar esto? Je je, un cordial saludo.

martes, 16 de octubre de 2012

Cómo hacer una toma de requisitos

Dilbert y sus problemas con los requisitos
Hoy vamos a volver a las bases de la ingeniería del software, e intentaremos aclarar algunos conceptos.

Para la toma de requisitos pasaremos habitualmente por 3 fases:
  • Obtención de los requisitos candidatos. Para ello, pasaremos por las inevitables entrevistas a usuarios potenciales, análisis de mercado, realizando prototipos, etc.
  • Especificar los requisitos, lo cual pasa inevitablemente, por escribirlos y documentarlos.
  • Analizar los requisitos, estableciendo un profundo estudio de los requisitos, de forma que se dividan en sus más pequeños componentes.
Para la toma de requisitos, Steve McConnell en su Software Project Survival Guide propone un proceso más o menos secuencial de 9 pasos:
  1. Identificación de usuarios finales clave.
  2. Entrevista a dichos usuarios finales.
  3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
  4. Presentación del prototipo a los usuarios finales, solicitando feedback.
  5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
  6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
  7. Utilizar el prototipo como la primera línea de base de los requisitos.
  8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
  9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.
Por supuesto, hay que tener algunos puntos en consideración:
  • Todos los documentos anteriores, así como el prototipo, se pondrán bajo control de cambios a partir de su primera versión. Es fundamental no esperar a fases posteriores, ya que el versionado no es sólo para controlar lo entregado al cliente, sino que nos evita múltiples problemas, proporciona agilidad (especialmente cuando hay que echar cambios atrás), y apenas nos quita tiempo (sobre todo si se automatiza).
  • El prototipo no necesita tener código. Existen herramientas de prototipado basadas en flujos de acciones, flujos de procesos. Pero también las hay que simplemente dibujan pantallas. Un simple PowerPoint puede ser una herramienta de prototipado ágil, y efectiva. Un powerpoint es fácil de reproducir en cualquier dispositivo (PC, tablet, móvil, ...), no requiere instalación...

En las próximas entradas, revisaremos en detalle cada uno de estos puntos, y cerraremos el ciclo completo de toma de requisitos desde la experiencia.

sábado, 6 de octubre de 2012

Sobre Testing Quadrants


Hoy veremos un tema que no es nuevo, pero que me era desconocido hasta hace poco: los testing quadrants.
Fuente: libro "Agile Testing: the book"

Esto de los testing quadrants parece estar originalmente basado en la visión de Brian Marick en su blog (http://www.exampler.com/old-blog/2003/08/22/), y consiste en clasificar los diferentes tipos de tests desde dos puntos de vista:
  • Orientación: los tests varían entre los más orientados al negocio (Business Facing), y los más orientados a la tecnología (Technology Facing).
  • Tipo de test: a la izquierda, los de soporte al equipo (Supporting the team). A la derecha, los que critican al producto (Critique Product).
A partir de las ideas originales de Brian Marick, esta idea de los testing quadrants se desarrolló en el ya famoso "Agile Testing: the book" (http://agiletester.ca/), de donde está sacada la imagen que preside este post.
Tal y como se habla en algunos blogs, la numeración Q1, Q2, Q3, Q4 y el uso que se les suele dar a los tests, no pretenden indicar que estemos hablando de la nueva metodología "Cascada" para los tests. De hecho, la numeración es arbitraria. A continuación, veremos que no están desencaminados.
Sí es cierto que en diversas fases del proyecto, es habitual que se utilicen tests ubicados en distintos cuadrantes. Esto es por la forma en que están diseñados los cuadrantes.
Los cuadrantes 3 y 4 suelen exigir que ya exista un conjunto bastante bien definido de código instalable. Los cuadrantes 1 y 2, suelen utilizarse en las primeras fases, por su naturaleza automática (Q1) y facilidad para el prototipado (Q2).
La idea de los cuadrantes es clasificar las técnicas de text, no proporcionar una secuencia natural  y férrea (como el ya manido método de desarrollo en cascada).
Os recomiendo explorar los enlaces para ampliar este interesantísimo tema.