Método MoSCoW

El método MoSCoW es una técnica de priorización de requisitos basada en el hecho de que aunque todos los requisitos se consideren importantes es fundamental destacar aquellos que permiten darle un mayor valor al sistema, lo que permite enfocar los trabajos de manera más eficiente.

Lo que la diferencia de otras técnicas tradicionales como por ejemplo calificar los requisitos como de prioridad alta, media o baja es que en este caso la escala utilizada tiene un significado intrínseco, de manera que el usuario responsable de asignar la prioridad conoce el efecto real que producirá su elección.

M (Must): Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.

S (Should): Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.

C (Could): Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.

W (Won’t): Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.

Esta clasificación puede ser modificada durante el proceso de desarrollo y definirse, en el caso de desarrollos iterativos incrementales, prioridades a nivel de iteración.

Desarrollo de software. Limitar el valor no debe ser el objetivo

No digo nada nuevo si os comento que las mejores especificaciones de los usuarios van surgiendo conforme se va avanzando en el proyecto y se les empieza a despejar la niebla que se extiende por su visión de lo que debe ser el sistema de información.

En un enfoque clásico, pretender acertar desde una fase de análisis que se encuentra muy lejos del momento en que se va a poner el producto en producción es casi una quimera por mucho que se haya trabajado con prototipos y los desarrolladores conozcan bien al negocio y a los usuarios.

¿Cómo mantener una agenda de plazos y presupuesto si me cambian los requisitos? No se puede salvo que termines reventando al equipo y/o recortando el alcance (y calidad) del sistema de información y aún así probablemente te termines desviando en ambos.

Si nos quedamos con las especificaciones iniciales no se puede esperar un producto con un mayor valor que el que nos ofrecen las mismas porque estamos limitando el valor al no permitir cambios propiciados por el feedback usuario.

Por tanto, no solo nos estamos encontrando con una estrategia de desarrollo de software que se aleja de la realidad de los proyectos sino que, además, su orientación a la agenda, ofrece menos flexibilidad para incorporar valor al producto a lo largo del proceso de desarrollo.

Desarrollo de software. Software que funciona

Trabajamos para eso, para desarrollar software que funciona. Pero, ¿de qué se trata eso de que el software funcione?. Cada uno tenemos diferentes perspectivas de las cosas, esta no iba a ser una excepción, por lo que para cada uno el listón puede estar a diferente altura y no necesariamente (dependerá del momento del proyecto, del contexto, de las características del sistema de información, etc…) unos tienen que estar siempre equivocados y otros estar en lo cierto.

Siguiendo un enfoque iterativo incremental vamos a ir liberando diferentes versiones del producto hasta obtener una “versión final” (lo pongo entre comillas porque el software es generalmente objeto de una continua evolución por lo que se puede hablar de versiones finalistas de un proyecto más que versiones finales de un sistema de información).

Independientemente de que desde el primer momento intentemos liberar el mejor software posible (desarrollo con intención) es razonable pensar que en las primeras iteraciones de una aplicación el listón no esté tan alto, sobre todo en aquellos casos donde esas iteraciones no llegan a un entorno de producción o de llegar su uso está limitado a su evaluación y porque la incertidumbre y falta de acoplamiento (al proyecto y entre las personas) en los momentos iniciales hace que se falle más de la cuenta (desarrolladores y usuarios).

No se trata de relajarnos en las primeras iteraciones, no quiero decir eso, sino de entender que no todos los momentos del proyecto son iguales (ni todas las circunstancias). No hay minutos prescindibles en un proyecto porque lo perdido no se recupera y por ese motivo siempre soy partidario de ir con intención siempre sin olvidar y, eso es lo que quiero dejar patente, que como en toda carrera de larga distancia hay que saber regular (y que todas las carreras son diferentes).

Un software que funciona debe satisfacer las expectativas del usuario. Si no satisface sus expectativas tenemos un producto que hace cosas pero no tal y como las quiere el usuario. No se trata de términos absolutos sino que tenemos que tener en cuenta los umbrales, es decir, la liberación de una nueva versión puede que no deje totalmente satisfecho al usuario pero sí supere sus umbrales de satisfacción. Nuestro objetivo será que la “versión final” esté más cerca de la total satisfacción del usuario que de su umbral superior pero eso requerirá mucho trabajo, voluntad por parte de los usuarios para darnos su feedback y diferentes evoluciones del sistema.

Un software que funciona no debe quedarse solo con la parte visible del iceberg. La deuda técnica cuenta y mucho. El usuario no la ve, no la valorará y sin embargo condicionará la mantenibilidad del producto y la disponibilidad del sistema ante futuras evoluciones del mismo. Es posible que haya clientes que no la tengan en cuenta, en cualquier caso soy de la opinión de que los proveedores deben marcar unos estándares de calidad para los sistemas que desarrollan, como elemento diferencial respecto a los que no lo hacen.

Más allá de la deuda técnica se encuentra la mantenibilidad (un concepto más general). Un software que funciona debe ser lo más fácilmente de mantener posible (dentro del contexto en el que se ha realizado el proyecto) y eso va más allá de la deuda técnica pudiendo contemplar elementos documentales si así fuera preciso.

Un software que funciona debe tener también en cuenta aspectos no funcionales. Algunos de ellos están en la parte visible del iceberg (aunque tal vez en la parte de atrás, la que no se ve a simple vista o la que requiere más tiempo para ser descubierta) como por ejemplo el rendimiento o la disponibilidad y otros en la parte no visible como por ejemplo la seguridad.

Desarrollo de software. Todos en el mismo barco

Una de las labores más complicadas de un gestor de proyectos en aquellos casos en los que existen múltiples equipos de trabajo que pueden pertenecer incluso a proveedores diferentes (tampoco resulta sencillo hasta en aquellos casos en los que existe un solo equipo formado por pocos desarrolladores) es que todos comprendan cuáles son los objetivos y las restricciones que existen para alcanzarlos.

Resulta especialmente complicado sobre todo en aquellos equipos que están desarrollando funcionalidades o herramientas complementarias al núcleo el sistema, en primer lugar porque la atención del gestor estará más orientada a la línea principal de desarrollo del producto así como a eliminar o paliar las posibles resistencias que puedan existir en cualquiera de las distintas líneas y en segundo lugar porque, por el mismo motivo, se encontrarán a distancia del product owner y de los directores usuarios y contemplarán desde más lejos sus expectativas y su presión.

Hay proyectos donde el trabajo de estos equipos secundarios es igualmente secundario pero en otros casos el resultado de su trabajo puede ser esencial para el funcionamiento y/o para la puesta en marcha del sistema. Tanto en un caso como en otro (aunque por supuesto mucho más en el segundo) es necesario que esos equipos mantengan el enfoque y la tensión en el proyecto, de la misma forma que lo hacen aquellos equipos que están peleando con las partes más críticas del sistema.

Como decía, esto no es fácil, ya que resultaría fundamental que el product owner y los directores usuarios les expresasen directamente y de forma constante (continua) sus expectativas y eso es algo que resulta complicado en proyectos con una cierta envergadura. Ahora bien, si no es posible llegar a eso cualquier aproximación ya supone un avance. Si el equipo no termina de asimilar la situación, el gestor de proyectos debe actuar y en estos casos es mejor un falso positivo (pensar que el equipo no es consciente de la situación e insistir) que creer que se ha asimilado y no actuar.

Cuantas más personas se suban al barco más posibilidades hay de sacar el proyecto adelante, sin olvidar que hay que procurar que quien suba no vuelva a bajar (de ahí la importancia de las actividades necesarias para que los equipos y los desarrolladores mantengan el enfoque en el proyecto).

Desarrollo de software. Sacar requisitos a la superficie

Existen requisitos que tardan en salir a la luz. A veces el usuario lo da por entendidos, en otros casos se da cuenta más tarde o bien se trata de ajustes sobre alguno de los ya especificados.

Es complicado traducir la imagen abstracta del sistema de información que el usuario tiene en la cabeza que en la mayoría de los casos está como cubierta con niebla y que solo se empieza a ver con claridad cuando nos aproximamos a ella (conforme el usuario tenga más claro el producto final con el que se va a encontrar).

Es importante sacar cuanto antes estos requisitos ocultos a la superficie porque a su vez pueden sacar a la luz otros requisitos ocultos y porque pueden tener importancia en el resultado final del producto. Para ello es importante aplicar enfoques iterativos incrementales para que en cada iteración el usuario esté más cerca del producto final y empiece a ver con mayor nitidez determinados aspectos del producto que está esperando así como aplicar otras estrategias o instrumentos como puede ser el prototipado.

Si el usuario no solicita cambios sobre las especificaciones iniciales es una señal de alarma ya que lo más probable es que no haya dedicado suficiente atención a la especificación de los requisitos, a la revisión de los mismos o a las diferentes iteraciones del producto que se están liberando. ¿Es posible que se haya acertado a la primera? Sí, es posible pero yo por si acaso pondría un intensa luz parpadeante de color rojo como alarma.

Donald Norman. El producto lo tienen que definir los usuarios

Uno de los problemas que nos podemos encontrar con frecuencia en un proyecto de desarrollo de software lo tenemos cuando el desarrollador piensa que sabe tanto del negocio como los usuarios y se olvida de que el producto no es para él sino para los usuarios.

Que un desarrollador conozca el negocio muy bien es algo muy interesante para el proyecto siempre y cuando no se caiga en el error de empezar a tomar decisiones sobre lo que le gustaría a él que hiciera el producto sin contar con la aprobación del usuario.

Siempre hay que contar con los usuarios. Un producto desarrollado a sus espaldas difícilmente se ajustará a sus necesidades reales. Generalmente cuando esto sucede es por culpa del área usuaria que se niega a dedicar al proyecto los recursos que son necesarios, dejando todo el peso a los desarrolladores. Esta situación es necesario revertirla cuanto antes y en caso contrario intentar cerrar el proyecto con el menor daño posible entre las partes, si bien, no siempre será posible una cosa o la otra porque el nivel de toma de decisiones al respecto se situará en otra escala de la organización que tendrán sus propias políticas y criterios.

Si contamos con la ayuda y dedicación del usuario y sin embargo tomamos decisiones funcionales por él, estamos cometiendo un grave error.

Al respecto me parece interesante la siguiente reflexión de Donald Norman: “Los diseñadores no son usuarios típicos. Llegan a ser tan expertos en el uso de los objetos que se han diseñado que no pueden creer que alguien más pueda tener problemas. Sólo la interacción y pruebas con usuarios reales en todo el proceso de diseño puede evitar eso”.

Desarrollo de software. La flexibilidad del Product Owner condiciona la flexibilidad del equipo de desarrollo

Soy partidario de no retrasar las entregas que se fijan. Es cierto que no siempre he pensado he pensado así y tampoco os puedo asegurar que mañana no cambie de opinión ya que independientemente de que uno tenga un background el presente condiciona, y mucho.

Si no se va a llegar y el incremento de la capacidad del equipo no es suficiente o incluso empeora la situación, la solución pasa por renegociar con el Product Owner, con el área usuaria o el cliente (en general) el alcance de la entrega.

Esto no es fácil, nada fácil. El usuario lo querrá todo (y más allá) y por supuesto, en plazos, independientemente de todo lo que haya ocurrido desde que se inició el proyecto, incluso siendo consciente de que el retraso no es imputable al equipo de desarrollo.

Si el usuario no quiere reducir el alcance o no lo hace de manera suficiente sí que hay que plantear un retraso en la entrega. No creo en el overtime impuesto directa o indirectamente en los desarrolladores, sí creo en la responsabilidad de los mismos y en su capacidad de administrarse el tiempo (son muchos los desarrolladores que no funcionan bien así y como digo siempre, mejor trabajar con personas que se adaptan a tu forma de entender el trabajo), por ese motivo no puedo ser partidario de soluciones que supongan overtime. Sí es admisible un pico de trabajo, pero por supuesto compensado de alguna forma (siempre equivalente a los resultados y esfuerzo realizado) y no puede ser prolongado en el tiempo.

¿Qué tampoco puede haber retraso? No hemos nacido para hacer imposibles y mi recomendación es que si se sabe de manera cierta que no se va a llegar, se escale el problema. Mejor ahora que dar sorpresas desagradables más adelante.

Ahora bien, si existen posibilidades de llegar en plazos hay que intentarlo, advirtiendo siempre al Product Owner de lo ajustado que vamos a estar y levantando la mano en el momento en que veamos que no vamos a llegar. Si el Product Owner no ha sido flexible a la hora de acotar el alcance, tampoco debemos serlo nosotros a la hora de realizar cambios que supongan una desviación sensible de los objetivos.

Reconozco que eso es antiágil y anti todo lo que entiendo que debe ser el desarrollo de software pero no puedo borrar la realidad y el contexto del proyecto es ese. El contexto manda, se será ágil en lo que se pueda, pero esas son las condiciones, esas son las variables que manejamos.

Desarrollo de software. El conocimiento de las aplicaciones que se venían utilizando hasta ahora

Muchas veces cuando se decide desarrollar un nuevo sistema de información se quiere hacer tábula rasa y no tener en cuenta las aplicaciones o herramientas que venían utilizando hasta ahora. En alguna ocasiones la excusa es no dejarse contaminar por lo anterior en otros casos es que simplemente no interesa porque “no lo he inventado yo“.

Que el usuario te va a especificar lo que quiere no es suficiente para obviar lo que se venía utilizando hasta ahora. Es conveniente conocer los puntos fuertes y débiles de esas soluciones para evitar volver a caer en los mismos errores y para aprovechar todo lo positivo que tuvieran.

Los usuarios van a extrañar y mucho todo lo que en el anterior sistema les gustaba o les resolvía y el nuevo sistema no y hasta que dicha funcionalidades no las tenga el sistema o no estén ejecutadas acorde a sus expectativas, van a existir ciertas resistencias por parte de los usuarios sobre el nuevo sistema y que complicarán la puesta en marcha del mismo y el trabajo del equipo de desarrollo).

Otro aspecto positivo de tener en cuenta estos sistemas es que sabemos que al usuario le cuesta acertar con sus especificaciones (necesita iterar) por la diferencia que existe entre las expectativa que tiene y que están plasmadas en una imagen abstracta y la realidad del funcionamiento del sistema. Utilizando uno que está en funcionamiento y con años de feedback sobre el mismo tenemos un instrumento muy interesante que sirve de apoyo al usuario y a los desarrolladores.

Jim Highsmith. El aprendizaje es la esencia de la iteración

Jim Highsmith en su libro “Adaptive Software Development” realiza la siguiente reflexión: “El aprendizaje rápido requiere iteraciones: intentar, revisar, repetir”.

Aprender sobre hechos y no trabajar indefinidamente sobre hipótesis es para mi la esencia de la iteración.

Es cierto que la hipótesis dura (para bien, para mal o para regular) hasta que tenemos el resultado definitivo del proyecto en producción ya que hasta que de manera completa no se utiliza en un contexto real no podemos medir con precisión la satisfacción con el producto pero también lo es que la niebla se despeja poco a poco conforme el usuario va probando versiones parciales del mismo (en producción real preferiblemente) y va proporcionando su feedback.

En este proceso no solo aprende el desarrollador sino que también aprende el usuario porque de lo que cree que quiere (que no deja de ser una idea abstracta y a gran escala) a la solución que realmente le satisfaría, hay un largo trecho.

Desarrollo de software. ¿Por qué es mejor tener esa visión más global del negocio?

Sin esa visión global estás construyendo el sistema a base de retales de manera que funcionalidades que podrían tener una solución general, la tienen de manera particular y eso de lugar a más pantallas, más tablas, más código. Si el sistema es grande y se produce muchas veces este problema estamos haciendo un sistema más complejo, con un mayor coste, más difícil de mantener y más complicado de administrar (a nivel de aplicación).

Como decía en el artículo de ayer, no se trata de hacer un análisis completo del sistema, no me refiero a eso, sino a tener una visión global de qué es lo que se quiere hacer, no se requiere por tanto la formalidad de un análisis de un ciclo de vida clásico y tampoco seguir sus etapas.

Se puede analizar y empezar a construir, así vamos obteniendo feedback del usuario que nos será de mucha utilidad porque esa visión global que nos la da el usuario y el estudio de sistemas de información que viniera utilizando antes para ese mismo proceso (u otro similar existente en otra organización) sigue estando basada en un concepción abstracta del sistema y hasta que el usuario no empieza a ver cosas tangibles no saldrán a la luz comportamientos y funcionalidades que formaban parte de sus expectativas pero que todavía no habían salido a la superficie.