Toma de Requisitos - Paso 6: Completar el prototipo

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 6: completar el prototipo.

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.

Una vez hemos llegado a este punto, y tenemos una guía de estilo en condiciones, podremos pasar a completar el prototipo hasta hacerlo totalmente funcional.

Ojo, no estamos diciendo que el prototipo se acabe convirtiendo en la aplicación final. Esto ha sido ampliamente discutido en muchos foros, y tiene sus defensores (especialmente en el ámbito del software ágil) y sus detractores (especialmente desde el punto de vista de la ingeniería del software).

De esta forma, se consigue que los desarrolladores tengan una visión completa de lo que será el producto final. Hay dos visiones:

• La visión del producto permite alinear el trabajo de los desarrolladores.
• El prototipo detallado permite una visión mucho más detallada, facilitando a los desarrolladores el trabajo.

El prototipo, llegados a este punto, deberá ofrecer toda la funcionalidad del software, con al menos:

• Todos los cuadros de diálogo, incluyendo los cuadros de diálogo estándar como Abrir, Cerrar, Imprimir, Guardar, etc.
• Todas las pantallas de inserción de datos.
• Todas las salidas de datos (pantallas, informes, listados...)
• Todas las interacciones con el sistema operativo (ejemplo: importación y exportación al portapapeles).
• Interacción con sistemas externos y otros productos de terceros.

El prototipo contendrá por tanto las principales interfaces:

• Con el usuario
• Con el sistema operativo
• Con otros sistemas externos

Llegados a este punto, tendremos que hacer una línea base (no olvidemos la gestión de la configuración, que sea un prototipo-borrador no significa que debamos correr el riesgo de perderlo!!).

Tal y como establece Steve McConnell en su magnífico libro Software Project Survival Guide:

"No deberías usar un prototipo como la base de software real, así como no deberías usar un decorado de Hollywood como base para una casa de verdad".

El prototipo es un callejón sin salida, útil, pero un callejón sin salida. No ha habido una arquitectura, no está preparado para construir sobre él la aplicación final. La mayoría de autores recomiendan construir el prototipo en un entorno y en un lenguaje de programación que facilite el desarrollo rápido, pero que claramente no vaya a usarse en el desarrollo final. Por ejemplo, úsese Visual Basic o un lenguaje similar de alto nivel, cuando el desarrollo final vaya a ser en Java o C++ o C#. Esto evitará tentaciones más adelante.

Ética e Ingeniería del Software

Fuente: http://www.asme.org/

Recientemente, en el blog de Javier Garzás he leído un post donde se propugna algo que llevo repitiendo hasta hartarme desde el primer post: que debemos comportarnos profesionalmente, de forma ética.

No somos charlatanes, patanes de feria que vendemos lo que nos convenga en función del beneficio que nos proporcione. En lugar de eso, damos al cliente lo que necesita en cada momento, maximizando su satisfacción y nuestro beneficio a largo plazo. Porque creemos en que la relación con nuestros clientes se cimenta en una confianza mutua, y ésta sólo puede realizarse a largo plazo.

Esta forma de pensamiento la he visto como eco en algún otro post. Me hace mucha gracia, que Javier afirma: "una metodología no es un equipo de fútbol, ni un partido político, ni una religión". Sin embargo, leo por doquier en la red continuas llamadas talibanistas a defender la religión del bloguero de turno:

• Metodologías ágiles
• Software libre
• CMMI
• Integración continua
• <Pon aquí tu práctica/metodología/marco de trabajo>

El pensamiento que defiendo es similar al promulgado por Alistair Cockburn hace ya unos años:

"Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento."

Por desgracia, hay gente que incluso afirmando defender estas ideas, confiesa sus prejuicios y reticencias al respecto de ciertas formas de trabajar: "metodologías", "prácticas", "marcos de trabajo"...llamadlo como queráis.

Podemos estar convencidos de una cosa, pero no debemos defenderla si no es con argumentos probados, objetivos y no sólo cualitativos sino también cuantitativos. Por desgracia, esta forma de pensar encaja perfectamente en los que yo llamo "indecisos patológicos" o "charlatanes del depende". Sí, ya los conocéis. Me refiero a los que siempre contestan a todo con un "depende" (hasta aquí todo va bien), pero que cuando se les pide algo más de detalle o chicha en su discurso, podemos tener dos tipos de respuesta:

• Verborrea coherente pero carente de fondo y forma, que al final no termina de dar ningún tipo de argumento veraz ni mucho menos objetivo hacia un lado u otro. Esta verborrea de político le viene muy bien a algunos individuos, que incluso les facilita la promoción profesional. Pero lástima de los clientes que acaben con ellos, y mucho peor: lástima de los que acaben en un proyecto dirigido por estos pseudo-profesionales.
• Verborrea que sólo está orientada a alimentar el ego del que escucha. Son los llamados aduladores, los pelotas, que difícilmente terminan hablando del tema, sino que redirigen la conversación a un terreno menos objetivo y relacionado con el proyecto en cuestión.

Al querer escribir yo este post, me he encontrado con otro post bastante interesante. En él, su autor deriva la conversación a la ética informática, y al colegio profesional. Este autor, plantea la existencia de un tribunal de ética. Yo no sé lo que pensaréis pero empiezo a estar harto de tribunales, comisiones, cortes, comités de supervisión, equipos de trabajo, etc, etc. Y estoy harto de apelar siempre a un "ser superior" que nos proteja y defienda.

Es muy fácil: lo único que puede definir el comportamiento ético o no en un proyecto es la documentación. Los criterios objetivos, y la forma en que se basan y defienden, es lo único que puede usarse como valor ético en un proyecto. Pero claro, decir esto cuando la moda es ir en contra de la documentación, ser ágil, y entregar todo de forma rápida (y sin documentación), es poco menos que escupir al viento. Pero no deja de ser cierto. No es posible verificar la ética en un proyecto sin contrastar el contrato, con las decisiones tomadas (y las decisiones, o se documentan...o se pierden). Y es así en todas las profesiones.

Después de todo, en una profesión en la que no hay estándares cerrados, en los que no hay normas internacionales que establezcan la forma correcta de trabajar, todo vale. No podemos a la vez defender que hacer software es un arte, y al mismo tiempo querer crear Colegios, Comisiones éticas que verifiquen el buen hacer...respecto a qué?

En fin...excelentes Alistair Cockburn en su comentario, y Javier Garzás y Jorge Ubeda en sus respectivos posts. Espero que esta pequeña reflexión mía haya podido aportar algo.

Cuando la culpa no es del usuario II

Recientemente he conocido a Martin, y me ha comentado que le ha gustado mi post "La culpa no es del usuario".

Martin es un profesional en un sector difícil y cada día más competitivo. Conoce, aunque no es profesional del sector, la tecnología en sus diversos ámbitos. Le tocó sufrir la desidia y dejadez de las empresas de telefonía móvil en España, que muchas veces no se molestan en tener actualizado su software.

Recientemente, Martin quiso probar la disponibilidad y cobertura en su domicilio de una conocida empresa operadora de ADSL. Para saber si había cobertura, tenía que rellenar un formulario. En el mismo, se le solicitaba su dirección y número de teléfono. Nada fuera de lo normal hasta ahí. Sin embargo, cuál no sería su sorpresa al comprobar que no funcionaba. La respuesta fue que su número de teléfono estaba equivocado. Martin lo comprobó una y otra vez. Pero la respuesta fue la misma.

El software estaba equivocado, no su número de teléfono. En España, los teléfonos fijos empezaban en "9". Sin embargo, algunas provincias, han ampliado su capacidad utilizando números que empiezan en "8". ¿Resultado? Aunque ya hace bastante tiempo que existen números de teléfono que empiezan en "8", el proveedor de ADSL seguía con un software obsoleto, incapaz de adaptarse a esta realidad.

¿Y ahora qué? Pues este conocido operador de ADSL ha perdido a un cliente. Ha hecho perder el tiempo a este señor (y seguramente a muchos más).

Como he dicho ya muchas veces en este blog, lo importante, la base de todo desarrollo son los requisitos. Y este caso es un claro ejemplo de requisitos mal tomados y mal implementados.

Además, fallaron las pruebas. No se definieron correctamente pruebas que recogieran las diversas posibilidades. Los casos de prueba no contemplaron las posibilidades.

Al final, por muy ágiles que seamos, por muy rápidos que queramos ser al poner un producto al mercado, no puede ser despreciando un mínimo de disciplina en estas áreas tan necesarias: requisitos y pruebas.

Gracias Martin por dejarme este comentario tan real como aleccionador.

Enfermedades del software: Singletonitis

Patrón Singleton en notación UML

De nuevo, una enfermedad del software que a más de uno le va a sorprender. Y sin embargo es muy pero que muy vieja. Al final de esta entrada tenéis unos cuantos ejemplos de fuentes que he utilizado y que me han recordado lo peligroso que es usar patrones sin conocimiento, pero especialmente, el más simple de todos: el patrón Singleton.

¿En qué consiste el patrón Singleton?

Este patrón es el más sencillo, y también uno de los más conocidos y utilizados. Básicamente, su propósito es asegurar que sólo exista una instancia de una clase dada.

Singletonitis, una definición

Bien, dada la definición anterior, el anti-patrón Singleton ha recibido el nombre de "singletonitis": desorden transitorio del programador, que le lleva al abuso del patrón Singleton. Algunos autores van más allá, y definen claramente al patrón Singleton como un verdadero anti-patrón (es más causa de problemas, que solución de ninguno: o como se suele decir, pan para hoy, y hambre para mañana).

En el libro "Refactoring to Patterns", el autor Joshua Kerievsky presenta el término Singletonitis, refiriéndose literalmente a "la adicción al patrón Singleton". Este autor, propone un tipo de refactorización que llama "Inline Singleton", cuyo objetivo es eliminar los Singletons innecesarios en una aplicación.

Hay muchos problemas con el patrón singleton. Demasiados. Algunos de ellos:

• Crea una alta dependencia en el código. Un alto acoplamiento que es fuente de problemas
• Crea problemas con las pruebas y su automatización, especialmente por la alta dependencia del código al tratar de hacer pruebas unitarias.
• Problemas con el multi-hilo y concurrencia.
• Alta probabilidad de crear spaguetti-code, difícil de leer e incluso de debuguear, por acumulación de uno o varios de los anteriores.
• Problemas de reusabilidad. Lo mismo, por acumulación de uno o varios de los anteriores.

En uno de los artículos que he revisado, el autor (Taskinoor Hasan ), ha tratado de hacer una aproximación seria, tratando de dar una solución lógica a los diversos problemas que el autor va detectando en su inocente implementación del patrón Singleton. De tan serio que es el artículo, y la acumulación sucesiva de problemas que presenta, acaba siendo hasta ridículo y divertido.

Del tema de la concurrencia y problemática con los entornos multi-hilo, hay varios artículos que presentan estrategias más o menos eficaces en función de la situación, lo que complica la resolución del problema. Y es que hay que ver lo bonito que es todo cuando en nuestra ignorancia, planteamos un sistema con Singletons creyendo que éstos van a ser instancias mono-uso. Con el paso del tiempo, la experiencia (y la dura realidad), nos van enseñando que al ver las cosas desde un nivel superior, o al tratar de reutilizar componentes, nuestro pequeño patrón Singleton es una fuente de problemas. Además, esos problemas al haber tanto acoplamiento en el código y dificultad de testeo, son complicados de detectar y resolver.

Frases como "esto nunca se va a usar en multi-hilo", tan categóricas, deberían ir siempre acompañadas de un "zas, en toda la boca".

Es duro ver cómo la falta de previsión y el abuso de patrones (patronitis), hace que las cosas se usen fuera de contexto y acaben haciendo todo menos aquello para lo que fueron diseñadas.

Solución: ¿vacuna o erradicación?

No son pocos los autores que defienden la total prevención mediante la erradicación de la causa de la Singletonitis, evitando dicho patrón.
Otros, elaboran complejísimas estrategias para detectar problemas, incompatibilidades, etc. Incluso existe una estrategia de validación dentro del patrón llamada "Double Check Locking", diseñada para evitar que en el caso de multi-hilo, haya problemas derivados de los bloqueos necesarios dentro del patrón.
Yo propongo algo que varios de los autores defienden, y es el uso de otro patrón (que por supuesto tendrá su enfermedad asociada por abuso), y es el de IoC (Inversion of Control).

¿Y tú? ¿Ya has sufrido tu Singletonitis?...

Fuentes:

http://taskinoor.wordpress.com/2011/04/18/singleton_multithreaded/
http://www.antonioshome.net/blog/2006/20060906-1.php
http://pragmaticintegration.blogspot.com.es/2006/02/singletonitis.html
http://www.theserverside.com/discussions/thread.tss?thread_id=42116
http://www.gamedev.net/blog/32/entry-510687-why-are-you-infected-with-singletonitis/
http://msdn.microsoft.com/es-es/library/bb972272.aspx
http://www.teatromagico.net/foro/viewtopic.php?f=4&t=13513&p=454983
Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, 1995.
Kerievsky, Joshua: Refactoring to Patterns, Addison-Wesley, 2004.
http://weblogs.asp.net/sfeldman/archive/2008/10/22/singletonitis.aspx

La culpa no es del usuario

Hoy vamos a ver quién tiene la culpa de los fallos del software.
Me acabo de encontrar una referencia a mi antigua entrada "Cuando la culpa es del usuario", en la que yo bromeaba sobre quién tiene la culpa de los fallos en el mundo del software. Yo pensaba contestar o comentar en aquél blog, pero al final, había que registrarse y he desistido. Sin embargo, al ver los argumentos a favor y en contra, he pensado que hay que darle otra oportunidad a mi antigua entrada, y recuperarla, esta vez de forma algo más seria.

¿Quién tiene la culpa de los fallos del software?

Vamos a verlo con un ejemplo. Supongamos que hacemos una casa: planos, diseño, ejecución de la obra...todo. Y el usuario entra en la casa a vivir. Hemos construido la casa en base a las funcionalidades habituales: comer, desayunar, ir a dormir, ir al baño, entradas de luz, etc. Además, hemos cumplido las normativas existentes: seguridad, anchura y altura de puertas y ventanas, acceso de luz, aislamiento térmico, etc.

Supongamos que el usuario hace algo imprevisto como intentar salir por la ventana (y es un 8º piso). Si se muere, ¿está claro que es su culpa, no? Pero si le dejamos abierta la puerta al cuarto de alta tensión y no ponemos ninguna medida de seguridad...si se electrocuta y muere...quizás la culpa SEA NUESTRA.

Ahora supongamos que hace otras cosas como entrar por el garage en vez de la puerta de entrada, o tiene la absurda (o no tan absurda?) idea de comprar un sofá o una cama y éstos no caben por la puerta. Puede también querer mirar por la ventana, y encontrarse conque ésta da a la pared del siguiente edificio al que el nuestro se encuentra pegado (vamos, que sólo va a ver y tocar pared). ¿Quién tiene la culpa de esto?

Volvamos al mundo del software y veamos unos pocos casos más tecnológicos:

• El usuario entra en una parte no permitida del sistema. No podemos impedir que alguien obtenga una contraseña. Hasta ahí es cierto. Pero es nuestra responsabilidad como desarrolladores de software, que no sea posible acceder a partes del sistema restringidas, con una clave no autorizada. Esto me hace mucha gracia, porque tenemos la chulería de exigir que Windows sea super-mega-seguro...pero luego hacemos aplicaciones con más agujeros que un colador. Y entendemos que necesitamos un tiempo razonable para probar y corregir nuestros agujeros de seguridad (somos humanos, verdad?), pero no tenemos la misma tolerancia cuando en vez de desarrolladores, somos usuarios. Exigimos que el programa o sistema operativo que falla, se corrija DE INMEDIATO (los que lo programan no deben de ser humanos, sino robots). Y gratis. Y....vamos, que está claro que sabemos pedir...pero no dar. Exigimos derechos desproporcionados a los deberes que asumimos.
• El usuario juega con el sistema. Pues que juegue. Es el usuario. ¿Que lo rompe o cuelga haciendo alguna tarea prohibida? Para eso están los logs. ¿Que mete datos estúpidos o incorrectos? Para eso están los logs y el sentido común. Por supuesto, también están las validaciones de datos. Si permitimos "XXX" como fecha de nacimiento, probablemente la función de cálculo de Edad fallará.
• El usuario tiene que sacar su trabajo, que no es precisamente saber de la tecnología interna del programa. No tiene porqué saber si es puro Java, o JQuery...o lo que sea.

En fin, habría muchos más ejemplos que ahora mismo no tengo tiempo de abarcar. Pero sí me gustaría comentaros un caso real de un colega de profesión ha tenido, y que creo que va a ser representativo.

Caso real.

• Se trata de una aplicación web.
• En uno de los cambios de especificación, se añade soporte para iPad.
• La aplicación se prueba, y funciona correctamente en varios navegadores, tanto en Windows como en dispositivos iPad (hasta en Android!)
• Cuando llega el usuario, descubre que cierta funcionalidad, sólo está disponible con ratón: al pasar el ratón por encima de los elementos de la página, aparece una información específica de cada elemento. Esto, se introdujo por diseño para disminuir la información de pantalla. Y está genial. Pero un iPad no tiene ratón.
• Resultado: enfado del usuario y rediseño de la aplicación.
• ¿Quién tuvo la culpa?

Conclusiones:

Para acabar, resumamos las conclusiones de lo que hemos visto, y de lo que la experiencia me ha hecho ver en todos (y son muchos) estos años:

• El usuario no tiene culpa alguna de los errores que se producen.
• Es nuestra responsabilidad poner "paredes" y "puertas y ventanas" a la aplicación para permitir el acceso o no a las funcionalidades.
• Es nuestra responsabilidad cumplir las normas y estándares existentes, así como adaptarlos no sólo al tipo de usuario, sino al entorno (hardware y sistemas software con los que interactúe).
• Es nuestra responsabilidad identificar posibles interacciones del producto con otros productos, y ponerlo  como funcionalidades (si funciona) o restricciones (si no funciona).
• Es nuestra responsabilidad probar. Y probar todo, o asumir los riesgos de lo que no se prueba. Leía recientemente un post donde un compañero de profesión decía que no se puede cubrir todo con las pruebas. Y es cierto. Pero eso no significa que nos tapemos los ojos e ignoremos los riesgos.
• Automatizar es la clave: debemos hacer pruebas unitarias, y automatizar también las funcionales en la medida de lo posible. En el caso real que se ha mencionado, el problema no era del usuario, era de que no se hicieron todas las pruebas en todos los entornos. Si probar todo en tu PC cuesta 2 días...añadir un nuevo entorno (iPad), costará el doble (bueno, es una primera estimación).

Toma de requisitos - Paso 5: Crear una guía de estilo

Hoy vamos a ver el paso 5º de la guía sobre toma de requisitos.

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.

Los usuarios han aceptado y validado el prototipo (sí, eso fue el Paso 4 anterior). Así que ahora, los programadores deberían crear una guía de estilo: un pequeño manual o guía que identifique los estándares de estilo a seguir durante el inminente desarrollo software.

A ver, que esto no es una metodología: no hacen falta 200 páginas. Ni 20. Seguramente, con un par de páginas será suficiente. Habrá que añadir:

• Estilos visuales
• Imágenes con las pantallas más representativas (los 2 o 3 tipos de pantallas o cuadros de diálogo a mostrar).
• Ubicaciones de los botones, incluyendo los más habituales (Aceptar, Cancelar, etc).
• Estilos visuales: efectos, colores, tipos de letra.
• Mensajes de texto a mostrar. Se trata de buscar una terminología común, que todos los conceptos tengan un nombre único, usado de forma consistente en todas las pantallas, y sea un nombre familiar en el contexto del negocio del cliente.
• Estándares existentes a los cuales nos vamos a adherir sobre todo a nivel de usabilidad y accesibilidad.

Por supuesto, tras completarla, deberá revisarse y hacer una línea base (ponerla bajo control de cambios). Para esto no hace falta nada del otro mundo: un subversión o un repositorio similar bastarán.

Los estilos visuales, cuanto antes sean definidos, más fácilmente lograrán que haya consistencia en la interfaz de usuario. Después de todo, los requisitos cambiarán. Pero el aspecto visual ,es un buen sitio por el que empezar como base.

Para finalizar, van algunos estándares o normas relacionadas con los interfaces:

• ISO/IEC 9126: evaluación de productos software.
• ISO 9241: requisitos ergonómicos para trabajar con terminales de presentación visual (VDT)
• ISO/IEC 10741: interacción de diálogos.
• ISO/IEC 11581: símbolos y funciones de los iconos.
• ISO 11064: diseño ergonómico de centros de control.
• ISO 13406: requisitos ergonómicos para trabajar con presentaciones visuales basadas en paneles planos.
• ISO 13407: procesos de diseño centrados en la persona para sistemas interactivos.
• Guías de estilo para la web: IBM, W3C

Toma de requisitos - Paso 4: Presentar el prototipo

Hola, hoy vamos a ver el paso siguiente (Paso nº 4 en nuestra secuencia) en la definición de los requisitos, y para ello, tendremos que presentar a los usuarios, el prototipo que con tanto mimo hemos creado.

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.

En primer lugar, hay que hacer notar que la primera versión de un prototipo difícilmente va a gustar a los usuarios. Es algo normal, sus expectativas no van a cubrirse en esta primera versión.

Lo que hay que buscar en realidad es el feedback de dichos usuarios clave: sus comentarios son oro. Y lo son, porque tan sólo cuando esos usuarios ven el prototipo, la maqueta de nuestra aplicación, es cuando van a darse cuenta de detalles que habían pasado por alto, de información que difícilmente podría ser obtenida de otra manera.

Por supuesto, a los usuarios hay que dejarles claro que es un prototipo: ni hemos tenido un avance del 40% del proyecto en dos días, ni los problemas que vayan a surgir en la revisión han de ser tenidos en cuenta. Hay que tranquilizar a los usuarios en este sentido: aún estamos muy lejos de cerrar el prototipo, y por tanto, aún más lejos de tener avanzado el desarrollo del producto.

Es en esta fase cuando tendremos que hacer un auténtico ejercicio de usabilidad: conseguir no sólo que los requisitos se satisfacen, que han sido correctamente identificados. Además de esto, el producto debe ser sencillo, lógico, fácil de usar.

Es importante notar que en esta fase, hay que estar volcado al 100%, y hay que tener experiencia en el área que estamos prototipando. Si no es así, ni va a ser sencillo de usar, ni tampoco va a satisfacer las necesidades de los usuarios.

El objetivo final de esta fase es conseguir el apoyo, la excitación de los usuarios al lograr consciencia de que efectivamente, hemos entendido sus necesidades, y además, el producto va a facilitarles el día a día. No se trata de "satisfacer requisitos", sino más bien de satisfacer a los usuarios finales.

En esta fase, puede pensarse que se está perdiendo un tiempo precioso en algo que va a tirarse a la basura. Después de todo, ese es el final de todo prototipo. Nada más lejos de la realidad. Al contrario, todo el esfuerzo invertido facilitará y acelerará el desarrollo posterior, evitando problemas, revisiones, y cambios de última hora.

Como ya he comentado, es fundamental aclarar a los usuarios que el producto es un prototipo, un mero "esbozo" de la realidad que aún está por construir. Por eso, al final, vuelve a servir lo que comentaba en el artículo anterior, en el paso 3: las herramientas de prototipado simples como el Paint o PowerPoint, o un dibujo en un papel, son mucho más efectivas. Esto es así porque el usuario las percibe como algo realmente temporal, no aprovechable. Si nos liamos a hacer mucho código, HTML, css, JavaScript, menús desplegables, etc, etc el usuario pensará que lo que está probando es ya un producto real. Después de todo, se instala, se usa, y da resultados como un producto real. Si caemos en la trampa de dar un prototipo demasiado realista, el cliente pasará a meternos presión, ya que pensará que le estamos engañando, y que en realidad, tenemos ya avanzado buena parte del desarrollo.

Es importante dar también una fecha límite a la fase de revisión del prototipo: 2 o como máximo 3 revisiones de prototipo, deberían ser suficientes. Si nos alargamos en su revisión, sí que podremos poner en peligro el plan general del proyecto.

Si quieres volver al índice haz clic en: Índice.
También puedes ir al paso anterior de la toma de requisitos haciendo clic aquí: Paso anterior.

Toma de requisitos - Paso 3: Cómo hacer un prototipo

Para que tu prototipo sea a prueba de idiotas...busca uno

Hacer un prototipo no es tan fácil como parece. Conviene seguir unas reglas, para que a la hora de continuar el desarrollo, no nos encontremos con problemas. Veamos un poco de qué hablo.


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.

Simple.

El prototipo ha de ser simple. Se trata de ofrecer al usuario alternativas, de que pueda explorar cómo va a ser el sistema. Es por tanto el momento de explorar, de ofrecer opciones en cuanto a usabilidad, estilos, etc.

Alcance.

Se trata de ahorrar esfuerzos. No hace falta explorar todas las posibilidades, de abordar todos los casos de uso. De ofrecer todos los mensajes de error. De lo que se trata es de que el usuario reciba suficiente feedback de cómo se va a comportar el sistema. Para ello, hay que definir un alcance limitado, para que los esfuerzos de desarrollo también lo sean.

Por ejemplo, nos limitaremos a realizar los principales casos de uso. Es más interesante que cubramos una operación completa de varias pantallas, que por ejemplo cubrir una acción en cada pantalla.

El usuario no va a ser consciente de que funciona todo o parte en cada pantalla. Lo importante es que hemos cubierto una parte mayor de la aplicación. Por ejemplo, en un ERP haremos un alta en almacén, un alta de cliente, un alta pedido de ese cliente, y facturaremos ese producto para finalmente, contabilizarlo. Un caso de uso simple de cada pantalla, de forma que se cubra una gran parte del sistema.

Es más importante obtener la visión del look&feel, de qué se hace y cómo.

Herramientas.

¿Qué herramientas utilizar?Las más simples. Podría utilizarse HTML puro y duro en lugar de Java o código .Net. Pero tampoco es descabellado prototipar con herramientas más cercanas al diseño como Visio, Powerpoint o el mismísimo Paint que viene de serie en Windows.

¿Porqué no usar algo más elaborado como una herramienta profesional de prototipado? Pues porque precisamente en esta etapa, y los seguidores de las metodologías ágiles lo sabrán muy bien, no sirven mucho. Y no sirven, no porque sean malas, sino porque en esta etapa los requisitos aún son muy volátiles. Estas herramientas de prototipado pretenden ahorrar esfuerzo posterior, creando un sistema aprovechable. Sin embargo, el sistema no se va a aprovechar. El gran número de cambios lo echaría atrás. Claro, esto no ocurre cuando los requisitos tengan poca volatilidad. En ese caso, el sistema sí que puede prototiparse con herramientas que nos permitan en el futuro aprovechar los flujos, la estructura, o incluso el código.

Una recomendación: por simple que sea nuestro prototipo, si tiene código, siempre puede tener un error. después de todo es un prototipo. ¿Vamos a poner código de gestión de errores? ¿De logging? ¿Y qué más? ¡Si no hace falta! Queremos mostrar qué se va a hacer, nada más. Una pantalla Powerpoint, una imagen hecha con una herramienta de dibujo rápido, sería suficiente. Que la herramienta haga el trabajo por nosotros: para pasar de una pantalla a otra, usemos las acciones de Excel, de Powerpoint por ejemplo.

Otra ventaja de los prototipos hechos como "documento", es que difícilmente tienen errores. No dependen del PC en que se van a ejecutar. Se pueden mandar al cliente, ejecutar directamente desde un correo, sin instalación. Ni siquiera hace falta que se copie una carpeta con código HTML en el escritorio. Con que esté instalada la aplicación (Word, Excel, Powerpoint...es suficiente). Con algunos productos, es posible convertirlos en "ejecutable", de forma que en cualquier PC con Windows funcionen.

 

Detalles.

Los detalles, hay que cuidarlos pero con mínimo esfuerzo. ¿Que hay que sacar un informe al pulsar el botón "Imprimir"? Pues se muestra un documento de texto simulando el informe, o se muestra una imagen que muestre un informe típico.

Si queremos ahorrar esfuerzo mostrando datos encolumnados, nada más simple que usar una Excel, pegar ahí los datos a mostrar, y al ocultar la cuadrícula de fondo...¡premio! Tenemos un report simulado. También podemos simular la paginación, poniendo imágenes en celdas de forma que parezcan el botón "siguiente", y que dicho botón sirva de hipervínculo a la página siguiente del informe (también simulada, por supuesto).

Esfuerzo

Con todo lo dicho, hay que conseguir máximo en diseño, estilo y apariencia...pero con el mínimo esfuerzo. Si los datos son fijos, o se muestran en una imagen, no importa. Pero el esfuerzo por pantalla o acción debe ser el menor posible.

Es muy importante repartir adecuadamente el esfuerzo durante el prototipado. Si contamos con equipo que conozca el diseño gráfico, utilicémoslo. Si alguien conoce Powerpoint y su facilidad para crear vínculos y botones que nos lleven de una slide a otra...adelante. Es mejor que el equipo se sienta a gusto y explote una herramienta, que nos perdamos intentando usar la última "mega-herramienta-de-prototipado" del mercado.

La profundidad funcional ha de ser muy liviana. Si dedicamos por ejemplo más de 1h por pantalla, ya es demasiado. Mejor centrarse en pintar el aspecto y que "de el pego", que dedicar la hora a cargar datos XML y aplicar una hoja de estilos.

Como veo que el artículo me está saliendo muy largo, si no os importa, dejaré para una segunda parte todo lo que tengo en mente seguir contando sobre los prototipos.

Para ver el índice de artículos sobre Toma de Requisitos, haz clic aquí.
Para ir al paso anterior (nº2: Entrevistas), haz clic aquí.

Consigue Windows 8 a precio de saldo

Pues sí, es posible encontrar Windows 8  a precio de saldo. Lo puedes obtener por unos: 60, 30 y 15 euros (aproximadamente), o incluso menos.

• El precio normal, de unos 60 euros, ya lo tendréis en la mayoría de tiendas y centros comerciales.
• Para conseguirlo por sólo 29,99 euros, basta con que te apuntes a la oferta online que Microsoft está estos días ofreciendo. Esta promoción es sólo para descargas por Internet desde Microsoft y finaliza el 31 de enero de 2013.
• Aún es posible exprimir más todavía el tema, y conseguir por unos 15 euros la última versión de Windows 8. En teoría basta con que hayas comprado recientemente un PC, y dicho equipo admita la actualización.
• Finalmente, está el tema de licencias por volumen. Al parecer, hay quien compra a Microsoft este tipo de licencias (normalmente orientadas a empresas), y luego revende por internet dichas licencias a unos 10 euros o menos. Ojo, habrá que ver si esto es realmente legal o no, o de si luego puedes tener problemas con la licencia.

Por lo demás, y a pesar de los comentarios que recibo, Windows 8 va muy bien. Es agradable de usar, sencillo y potente. Eso sí, el término sencillo va acompañado de su curva de aprendizaje. Hay cosas que cambian, y aunque es posible hacer todo sin la interfaz metro, los cambios están ahí.

¿Compatible? Pues tampoco encuentro mucha diferencia respecto por ejemplo a Windows 7, que rompió compatibilidad con muchos programas y juegos que dejaron de funcionar. De momento todo me funciona y bien.

Hay quien dice que Microsoft tendrá que echarse atrás y traer de nuevo el botón de inicio (que es uno de los cambios más traumáticos), entre otras cosas. Tiempo al tiempo. Decían lo mismo del Ribbon (la barra de iconos de las aplicaciones Office), y la verdad es que no ha sido así. Más bien al revés, lo encuentro cómodo al tener los iconos agrupados, y mostrando las opciones más habituales.

Un cambio acertado es el "Market" de Microsoft. Tienes miles de aplicaciones disponibles, y buscarlas es tan fácil como usar la misma "lupa" que usas para buscar cualquier otra cosa en tu PC. De hecho, se hace exactamente igual. Es entretenido el disponer de tantas aplicaciones gratuitas para casi todo.

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.

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.

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.

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.

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.

Nos gusta programar pero no documentar



La documentación debe estar al servicio del proyecto y no al revés

Efectivamente, no nos gusta documentar. Esta afirmación llevo muchos años oyéndola, diciéndola y sufriéndola.

¿Porqué no nos gusta documentar?
Pues porque no nos proporciona ningún beneficio aparente. ¿Me cambia en algo la vida si documento 1, 2 o 700 páginas? Probablemente no.
Pero claro, esto es porque lo afirmamos mientras documentamos. Documentar no da el mismo tipo de satisfacción a los programadores que tirar líneas de código. ¿Qué pasa si dejamos pasar los años y tratamos de mantener un sistema sin documentación? Pueden pasar dos cosas:

• Yo mismo soy el autor del código, y dependeré de mi memoria. Esto apenas me ha pasado el 10% de las veces (el mantener mi propio código pasado mucho tiempo). Y mi memoria, sobre lo cual me considero una persona normalita, no es capaz de retener todas las decisiones funcionales y técnicas que dan lugar a cientos, miles de líneas de código en cada proyecto.
• El autor del código no está. Bajo mi experiencia, esto me ha pasado alrededor del 90% de las veces. Bien porque he cambiado de empresa y tengo que lidiar con las perlas de otros, o bien porque la persona que lo hizo o empezó ya no está, y ahora yo tengo que mantener lo suyo. En este caso, dependeré de lo bien que el autor o autores lo hayan comentado. Pero como veremos a continuación, tampoco será de utilidad.

Documentar el propio código, no me resolverá nada. Con suficiente tiempo, es posible deducir lo que hace el código. Eso es como decir que si tuviéramos el código de Windows, nos arreglaríamos los problemas que encontrásemos (no tengo otra cosa que hacer si tengo un error, que ponerme a mirar millones y millones de instrucciones, probando a ver qué pasó y cómo arreglarlo). Pero es que estamos dando por sentado que solo tocamos código para corregir cosas, que en nada afectan al resto del código.

Ahí está la clave: no se comenta el código para tener documentación, sino para acelerar los cambios en el código siempre que el objetivo del mismo ni sus circunstancias cambien. Si las circunstancias, la interrelación entre componentes, los requisitos, etc cambian...de poco me sirve el código ni sus comentarios.

Me hace mucha gracia quien afirma que la mejor documentación es el código. Me preocupa y me hace dudar de si esa persona ha mantenido proyectos grandes y antiguos. Las realidades de la empresa cambian, los programas y módulos con los que interactuamos cambian...los sistemas físicos en la empresa cambian. Tener que tirar del hilo del código y sus comentarios para tratar de deducir decisiones antiguas es agotador...e inútil. Porque es el pasado.

Hay quien afirma y afirmará que el código documentado lo es todo gracias a las habituales "balas de plata": patrones de diseño y arquitectura, buenas prácticas, estándares de desarrollo...Eso está muy bien para pequeños cambios y proyectos no muy antiguos. Pero la realidad es que todo eso ha cambiado en el tiempo. Lo que hoy nos parece la piedra filosofal, mañana estará obsoleto y habrá otros patrones, estándares, etc. Mantener código antiguo nos suele llevar a criticar a su autor, simplemente porque no entendemos las "balas de plata" de aquel momento (bueno, de acuerdo, a veces también hay código antiguo realmente horrendo).

Otro problema está en la dispersión y el tamaño. Está muy bien mantener código con comentarios de módulos pequeños, o sistemas concentrados. ¿Qué ocurre si mi código tiene millones de líneas de código, miles de módulos distribuidos en docenas de aplicaciones? ¿Qué ocurre si no tengo siquiera visibilidad de parte del código o de las aplicaciones porque son de otras empresas?

Aquí de nuevo entran en juego la documentación y los estándares. El primer punto a documentar es siempre las APIs o interfaces. Tanto si son nuestras como si no. Un fallo en el código no sabremos si es porque está mal implantada una API, si está con una versión obsoleta...a no ser que tengamos la documentación actualizada de esa API o interfaz. Los comentarios y la documentación, han de satisfacer objetivos diferentes.

Otra razón ineludible de documentar es la esencia misma de la orientación a objetos: abstracción, encapsulación, etc. Una capa de la arquitectura no puede saber de otra. Lo mismo las funciones o módulos. ¿Entonces cómo rastreo las decisiones que abarcan varios elementos si están dispersos y no saben unos de otros? ¿O es que tengo que hacer un "meta-comentario" (comentario de comentarios)? En realidad, esto que acabo de decir, no es ni más ni menos que la documentación que queremos evitar.

La mejor documentación, es la que está orientada a complementar al código y sus comentarios. Habitualmente, se hace a través de los entregables típicos:

• Requisitos. Recogen a alto nivel las necesidades del sistema desde el punto de vista de cliente/usuario. Son las necesidades básicas. Podemos de alguna forma asimilarlas a las historias de usuario a muy alto nivel. Deben aclarar el qué se espera.
• Análisis funcional: Contienen el qué debe hacerse para lograr lo que espera el cliente. Es suficiente con definir lo que la parte de la documentación de diseño técnico ha de desarrollar.
• Diseño técnico: Si se da trabajo a un programador, un diseño técnico puede contener la resolución a problemas técnicos que se han previsto (los comentarios en el código ya comentan los problemas imprevistos).

¿Estoy diciendo que estos entregables deben hacerse? No, para nada.
¿Tienen que ser 3? Pues tampoco. El hacer 1, 2 o 3 documentos dependerá del contexto. Incluso  un breve correo puede ser un análisis funcional de un pequeño cambio. Y no necesitas más. Dependerá de la metodología que se haya definido para el proyecto, el tamaño del mismo, la experiencia...

Lo que digo es que los anteriores son entregables típicos y satisfacen una necesidad. Pero una metodología que obliga de forma rígida (las que por desgracia se implantan en muchísimas empresas), son la causa de las críticas que hay hacia la documentación y hacia las propias metodologías. Si la metodología no se adapta a la realidad del proyecto, será un obstáculo, no un acelerador del trabajo.

¿Cuál es el límite? ¿Hasta dónde documentar? Eso, por desgracia, lo da la experiencia. Yo suelo dar en mis formaciones una máxima: si el analista técnico tiene dudas, es que el funcional necesita más. Si el programador no sabe qué hacer, seguramente el diseño técnico cojea.

Ojo: tampoco quiero decir que no contestemos a la persona que ha de continuar el trabajo. Yo por ejemplo, en un cliente, revisaba la documentación técnica con los programadores, y o bien modificaba el diseño técnico sobre la marcha, o directamente les indicaba cómo quería realizar las cosas, y ellos por un lado, y yo por el otro, seguíamos cada uno haciendo código/documentos. De hecho, algunos programadores terminaban llevando a cabo una solución ligeramente distinta: ellos después me explicaban el motivo, y yo adaptaba el documento a su realidad. Cuesta tiempo llegar a este nivel de colaboración, pero es un placer trabajar así. Das libertad a quien está a pie de teclado soltando código, y al final, lo importante, es que la documentación y el código no se descuadren, y que el equipo sienta que hay cierta libertad de hacer las cosas.

Y un apunte final: todo lo dicho aquí, sirve para cualquier ciclo de vida: cascada, iterativo, RUP, scrum, etc, etc. Siempre alguien tendrá que empezar a trabajar partiendo de algo que le habrán dado: un documento, una servilleta, un post-it en una pizarra...


 

Documentación de Cierre de un Proyecto

Como respuesta a un lector que me presentaba unas dudas, voy a tratar de indicar qué es necesario al cierre de un proyecto y para qué sirve (o al revés: dadas las necesidades, ver qué documentos aplicarían en cada caso). Las metodologías suelen centrarse en el primer caso. Las guías, o las adaptaciones de una metodología, prefiero centrarlas en el segundo. Porque no se trata de hacer documentos (primer caso), sino de resolver necesidades (segundo caso).

En primer lugar, decir que esta documentación que voy a nombrar, trata de cubrir objetivos. Si los objetivos no aplican en el proyecto, o están cubiertos de alguna otra forma, se puede obviar cada documento. Además, el alcance de cada documento debe ser acorde al tamaño del proyecto, o de los riesgos asociados. Estoy harto de repetir por activa y por pasiva, una y otra vez, que las prácticas y los procesos, están al servicio del proyecto. Y no al revés. Y que si no aplica una práctica a un proyecto, y requiere de adaptación, pues se hace: se adapta, y se busca cómo cubrir los objetivos y la esencia del proceso.

Los documentos que harían falta serían:

1. Informe de cierre. Este documento suele estar en realidad compuesto por una serie de apartados o subdocumentos como:
• 1.1. Estado final del proyecto
• 1.2. Buenas prácticas
• 1.3. Lecciones aprendidas
2. Aceptación del cliente
3. Encuesta de satisfacción

 

1. Informe de Cierre.

1.1. Documento de Estado Final del Proyecto.

En respuesta a lo que el lector me preguntaba, este documento contendría la foto final:

• dónde dejamos la documentación y qué documentación dejamos
• qué objetivos se tenían, cuáles se han cumplido y cuáles no
• cumplimiento de estimaciones (esfuerzo, fechas, costes), incluyendo razonamientos y demostraciones de porqué hubo alguna variación.
• métricas de cierre: demostración de que los objetivos de calidad y de cierre se cumplen. Si es un desarrollo, podemos aquí demostrar cómo el número de defectos encontrados por período de tiempo ha disminuido drásticamente (esta podría ser una métrica válida). Estos criterios objetivos (métricas), podrían suponer el punto de arranque al equipo de soporte que recoja el testigo y arranque la fase de mantenimiento.
• etc.

1.2. Documento de Buenas Prácticas.

Este documento o apartado recogería la experiencia del proyecto en cuanto a buenas prácticas que se han seguido, y que han tenido éxito demostrado en el proyecto.

 

1.3. Documento de Lecciones Aprendidas

En este apartado recopilaríamos todas las experiencias recopiladas durante el proyecto a todos los niveles:

• Técnico
• Funcional
• Comunicaciones
• Gestión de equipos
• Gestión de riesgos
• Organización de entregas
• etc.

2. Aceptación del cliente.

Este documento, recopila una descripción del proyecto, nuestra labor y papel en el mismo, y en él el cliente reconoce que acepta los servicios prestados, que son adecuados en alcance y calidad. Es un documento que enviamos al cliente, y éste nos lo devolverá firmado, sirviendo como referencia y credencial para futuros proyectos.

 

3. Encuesta de satisfacción.

Sobre éste ya hablé en un anterior post "La eficacia de las encuestas de satisfacción".

Como me he extendido un poco, creo que habéis cogido la idea. Dejaremos para un post posterior el detallar estos documentos y el cómo adaptarlos a la situación real del proyecto.

Fuente: CMMi

Darth Vader: el mejor Jefe de Proyecto

Programador, tu falta de fe en Scrum me resulta molesta

Esta entrada está inspirada en otra bastante antigua, y que nombro al final. Recientemente, he visto otro blog en el que salía  el tema, y me ha parecido gracioso, interesante...y espeluznantemente real. Veamos porqué repasando los 10 motivos principales:

Número 10: Darth Vader prioriza de la forma más brutal.

Cuántas veces vemos a los jefes de proyecto priorizar de forma que si bien nos acerca al éxito, también supone un brutal esfuerzo y sacrificio por parte de todos...incluido (aunque no siempre) el propio jefe de proyecto.

Número 9: Vader toma decisiones basadas en datos objetivos, no rumores.

Un jefe de proyecto como Vader no se preocupa de lo que dicen, él prefiere verlo por él mismo. No escucha, y su liderazgo se basa en la escasa confianza en su equipo.

Número 8: Vader adquiere compromisos, y trabaja duro para cumplirlos.

Así es, el problema es que muchas veces obliga a trabajar a todo el mundo para que los compromisos que ha adquirido, se cumplan. Por desgracia, no todo el mundo sabe tomar la medida de los compromisos que toma...y se mete en más de lo que puede abarcar (en realidad, en más de lo que SU EQUIPO es capaz de abarcar).

Número 7: Vader, cuando es necesario, se aleja para recuperar la perspectiva y descansar.

Ocurrió en las películas, y ocurre en tu proyecto. Tranquilo, si en el momento más crítico, no le ves el pelo a tu jefe de proyecto...es que está "recuperando la perspectiva".

Número 6: Vader gestiona riesgos y expectativas...¡de forma preventiva!

También vimos en la saga galáctica a Vader gestionando riesgos preventivamente. Los buenos jefes de proyecto piensan en sus proyectos a la defensiva, pero los protegen de forma agresiva.

Número 5: Es un tío persuasivo.

Darth Vader lo es. Para eso tiene el poder de la fuerza. Y muy mal genio. Esto también lo comparten muchos jefes de proyecto, que confunden la persuasión con la agresión, la amenaza y la extorsión.

Número 4: Vader elige una metodología, y se mantiene con ella...hasta que no funciona.

Esto es también un perfil de un buen gestor, ser consecuente con las decisiones tomadas, y cuando los métodos no sirven, reevaluar la situación y modificar la estrategia para afrontarlo de forma distinta, cambiando toda la metodología si es necesario. Eso sí, quedaos lejos porque alguien ha de tener la culpa de sus decisiones.

Número 3: Para Vader, no hay problema grande que no pueda enfrentar.

Bueno, y así ocurre con muchos jefes de proyecto. Que abordan problemas y proponen soluciones que dejan perplejos a sus equipos.

Número 2: Nunca es demasiado tarde para hacer lo correcto.

Igual que Darth Vader, que se arrepintió en el último momento, un jefe de proyecto puede decidir en el último instante cambiar y evitar el desastre total tomando la decisión correcta (a veces, precisamente la decisión que su equipo lleva todo el maldito proyecto diciéndole que tome). Por suerte, este cambio del jefe de proyecto en la estrategia, salvará el proyecto y le dará todo el mérito y la gloria.

Número 1: Vader nunca tiene miedo de ensuciarse las manos.

Y tampoco lo tienen muchos jefes de proyecto. Algunos, se las manchan picando código, o rellenando documentos de todo tipo para aliviar a su equipo. Otros, se las manchan de otra forma: culpando a quien no se puede defender, o alejando del proyecto a los que pueden hacerle quedar mal. Después de todo...¿para qué buscar soluciones si pueden encontrar culpables?

Y nada más. Bueno, creo que mis comentarios se han desviado bastante del artículo original, así que podéis leer los dos enlaces que os copio sin que se os repitan mucho los conceptos.

Fuentes:
http://www.geekwire.com/2011/top-10-reasons-darth-vader-amazing-project-manager/
http://www.genbetadev.com/trabajar-como-desarrollador/darth-vader-el-jefe-de-proyecto-definitivo

Megathon Windows 8

¿Qué es el Megathon?

El Megathon de Windows 8 es un evento que tendrá lugar de forma simultánea en varias ciudades de España los días 7, 8 y 9 de Septiembre, y en el que se dará formación sobre desarrollo en Windows 8 y la nueva interfaz metro, y al mismo tiempo dará la oportunidad de desarrollar en equipos una aplicación metro para Windows 8, con la ayuda de mentores. Los mejores grupos por ciudad tendrán premio, y luego habrá una final entre los mejores de cada ciudad.

De esta forma, los participantes podrán medir sus aptitudes a la hora de desarrollar aplicaciones, recibiendo interesantes premios (incluso un Nokia Lumia 800) y además podrán participar en los Excellence Labs dónde un ingeniero de Microsoft les ayudará a que su aplicación cumpla con los requisitos de UX, rendimiento, seguridad y accesibilidad claves para publicar en la Windows Store.

Más información en el siguiente enlace.

¿Dónde tendrá lugar? ¿Hay alguno cerca de donde vivo?

Se celebrará en muchas ciudades. Todavía se están cerrando los detalles. La lista de ciudades donde se producirá, la podéis encontrar actualizada en el siguiente enlace.

¿Y puedo encontrar formación gratuita al respecto?

Pues claro. En el siguiente enlace, tenéis todo lo necesario para aprender a hacer aplicaciones con interfaz metro para Windows 8.

¿Estás interesado en participar?

Si es así, no te pierdas las bases del concurso y en el mismo enlace, la lista de jugosos premios: sí, sí, Nokia Lumia 800 para cada uno de los miembros participantes del equipo que gane en cada ciudad.

¿Y si quiero asistir y simplemente aprender a programar?

Pues también puedes asistir a las sesiones técnicas y recibir la formación. Mira en los enlaces que hay en este post, y podrás conocer todos los detalles.