David Lorge Parnas. Lo positivo de reinventar la rueda

Reinventar la rueda se considera un antipatrón, de hecho siempre se considera como algo improductivo e innecesario.

Dave Parnas lo ve desde un enfoque distinto: «No debemos olvidar que la rueda se reinventa con tanta frecuencia porque es una muy buena idea, yo he aprendido a preocuparme más por la solidez de las ideas que se inventaron una sola vez».

Esa visión de Parnas está asociada al cambio y a la evolución. Realmente estamos viendo una y otra vez ideas y productos que se han reinventado y que han supuesto una revolución en la sociedad y en nuestras vidas.

¿Cuántas veces se ha reinventado, por ejemplo, los teléfonos móviles o los dispositivos que utilizamos para escuchar música?.

Si se observa con perspectiva y teniendo en cuenta el tiempo, reinventar la rueda va acompañada de la propia evolución, sin embargo si se observa desde el momento presente (y también hay que hacerlo) determinados cambios no tienen sentido porque no aportan nada a la solución actual.

Por tanto, los valores absolutos de si es positivo o negativo reinventar la rueda no son reales ya que, como siempre, dependerá del contexto.

Aristóteles. El cambio

Decía Aristóteles que: «El cambio en todas las cosas es dulce».

Es dulce si se asimila el cambio, si se entiende que es inevitable porque cada día el mundo sigue girando.

Si no se asimila y se entiende que la situación actual es la adecuada y no va a cambiar es cuando llegan los problemas. Tal vez la situación sea adecuada, confortable, positiva, dulce incluso, y es bueno disfrutarla y sacarle todo el provecho posible, pero se debe estar dispuesto y, sobre todo, preparado, para el cambio.

La tecnología está en continua evolución, las personas también. Las organizaciones deben ser conscientes de eso, quien antes era un competidor insignificante tal vez sea hoy quien te esté quitando el mercado y lo peor no es eso, cada día surge nueva competencia más adaptada al contexto actual.

Los sistemas de información no son ajenos a los cambios, teniendo en cuenta que soportan procesos organizativos y que estos se van a ir modificando. El software tiene sentido si existe un usuario, si el usuario y/o su contexto, cambia, evoluciona y sabemos que es una característica inherente, podemos decir que la necesidad de cambio es también inherente al software.

Visión global, expectativas y valor

Hace un par de días publiqué un artículo en el que indicaba que las especificaciones contractuales, por regla general (y con las matizaciones que hice), suponen un freno o una resistencia al objetivo de tratar de conseguir el mayor valor posible con la inversión realizada.

En este artículo voy a tratar de exponer que una situación diferente (que no necesariamente contraria), que no otra es la pérdida de una visión global de lo que se pretende conseguir, también supone un riesgo importante.

¿Por qué? La clave se centra igualmente en el valor. El valor de cada historia de usuario desarrollada junto a las expectativas de lo que se pretende conseguir en el proyecto, siempre y cuando estas se adapten a la propia evolución de los trabajos y de la propia organización, es lo que permite conseguir el equilibrio.

Esa pérdida de visión de sus propias expectativas por parte de un product owner, cuando se empeña, por ejemplo, en refinar sobremanera funcionalidades que, siendo importantes, ya funcionan de manera adecuada, provoca que se sobrevaloren historias de usuario que puestas en contexto tienen un valor muy
inferior porque existen otras necesidades en el sistema que pueden que no tengan todavía un funcionamiento aceptable o ni siquiera se han abordado.

Pero la búsqueda de la perfección no es el único problema, también lo tenemos cuando el product owner se centra en aspectos relacionados con lo que le puede gustar o dominar más, dejando de lado, otros más ásperos, complejos o que requieran un consenso que no resulta siempre facil de conseguir pero que también resultan necesarios para tener un sistema de mayor valor.

La visión del proyecto y expectativas no son fijas pero existen o deben existir para poder dar el valor adecuado a cada historia de usuario en la que se trabaja y para ir orientando la línea de desarrollo del producto hacia lo que se pretende conseguir, de lo contrario es posible que no se centren los esfuerzos y la inversión en lo realmente importante.

Aplicaciones, expectativas y personas

En ocasiones se tienen expectativas demasiado altas de lo que una aplicación puede conseguir.

Se cree que, invirtiendo el dinero suficiente (que generalmente será menos del que realmente se necesita) se conseguirá tener una aplicación que, de un plumazo, te resuelva todos los problemas: que consiga integrar toda la información y que además, ésta sea de calidad, que resuelva los problemas organizativos y que permita incrementar la productividad en términos exponenciales.

El error se encuentra en varios puntos:

– El software lo hace inteligente las personas y para ello se tiene que acertar en las especificaciones de lo que se tiene que hacer. Todos sabemos que eso es complicado y que se requiere, generalmente, un enfoque iterativo incremental para conseguir, a través del feedback, ir acercándonos progresivamente a una solución deseable.

El recorrido puede ser más o menos largo y en medio pueden existir problemas, tales como un desgaste en las relaciones entre desarrolladores y responsables funcionales, que el presupuesto se agote, que el responsable funcional cambie y con él el enfoque que se le estaba dando al sistema, que cambien las prioridades de la organización, etc…

– La calidad de los datos es el resultado del trabajo que hacen las personas con la aplicación. Puedes desarrollar validadores, implementar mil restricciones, que al final siempre quedará todo en manos de los usuarios. Por tanto, se trata de un problema de carácter organizativo que el software puede ayudar a controlar/gestionar pero no se podrá ir mucho más lejos de ahí.

Hacer el software muy restrictivo, en ocasiones, no se ajusta a la realidad de funcionamiento de la organización, que requiere, precisamente, una mayor flexibilidad, a la vez que hace más complejo el software. Cuántas veces nos hemos encontrado, por ejemplo, con aplicaciones con infinidad de perfiles que hacen su administración y mantenimiento más engorroso, cuando en realidad, todo se hubiera resuelto con muchos menos.

– Si la organización no funciona, si cada departamento quiere funcionar de manera autónoma, sin una visión global, ¿qué se pretende que solucione el software?. Esta situación empeora cuando ese comportamiento lo tenemos en organizaciones con múltiples sedes dispersas geográficamente.

Si las personas no hacen un esfuerzo por solucionar este problema, ¿se pretende que sea una aplicación la que lo resuelva?.

Valor, proyectos y especificaciones contractuales

Siempre comento que la importancia del valor del producto resultante es mayor que la del presupuesto, siempre y cuando estén compensado o exista una descompensación a favor del valor (cuánto más virada esté la balanza en esta dirección, mucho mejor).

De ahí la importancia de tener un buen product owner, con criterio y que también sepa dejarse aconsejar por otros usuarios y por el equipo de desarrollo.

El valor muchas veces se encuentra limitado por las especificaciones contractuales, cuando éstas marcan una serie de objetivos, que lo mismo resultaban interesantes en el momento en que se redactó el contrato, pero que tal vez, durante la ejecución del proyecto dejen de serlo, o al menos, pierdan peso respecto a otras necesidades sobrevenidas o que aparecen como consecuencia de la utilización de la aplicación.

Cuando nos encontramos en circunstancias así, llegará el momento donde el contrato, salvo que se hagan (si se puede) modificaciones sobre el mismo, predominará sobre la posibilidad de conseguir un mayor valor.

El contrato es un elemento estático, el mundo no lo es y, en consecuencia, los proyectos de desarrollo de software tampoco lo son. Lo mejor es establecer especificaciones contractuales más abiertas, que permitan una mayor flexibilidad y margen de maniobra.

Eso no es lo mismo que firmar un cheque en blanco, sino de saber leer mejor el contexto y expresarlo en un contrato.

Como siempre, no hay soluciones absolutas, lo mismo puede ser conveniente en desarrollos concretos, ser extremadamente meticuloso con especificaciones y alcance (sobre todo en desarrollos llave en mano).

Épicas vs historias de usuario

Muchas veces nos encontramos con el término «épica» y no sabemos como encajarlos cuando tradicionalmente estamos acostumbrados a trabajar con historias de usuario.

Cuando estamos trabajando en un sprint, una posible estrategia de desarrollo la tenemos dividiendo todas o algunas de las historias de usuario en tareas, ya sea por cuestión de tamaño, por la posibilidad de dividir el trabajo entre diferentes desarrolladores, etc…

Una épica no es más que un nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades, módulos, subsistemas, etc… Es decir, se tiene en mente una imagen abstracta de lo que se quiere obtener con la épica (que se desarrollará probablemente en varias iteraciones), pero son las historias de usuario, su implementación en los sprints y el feedback los que terminan de darle finalmente la forma.

Octava ley de Lehman. Realimentación del sistema

Su enunciado es el siguiente: «El proceso de evolución del sistema es consecuencia de un proceso de realimentación (feedback) a diferentes niveles, de manera iterativa y por diferentes actores, y debe ser considerado como tal para conseguir mejoras significativas sobre cualquier base razonable».

El carácter evolutivo del desarrollo de software lo caracteriza durante todo su ciclo de vida. Es continuo, aunque se materializa mediante incrementos o iteraciones, que pueden ser mediante ciclos más o menos regulares o de forma más discontinua.

En cada evolución se tiene la posibilidad de recabar feedback a diferentes niveles, por ejemplo, calidad estática del código (utilizando algún analizador tipo Sonar), número de defectos que presente al producto, grado de satisfacción del usuario, mejoras o nuevas funcionalidades que quieran incorporar una vez que se han analizado las de la versión que se ha entregado, etc…

Con la información obtenida se pueden plantear diferentes acciones que debidamente priorizadas pueden mejorar la calidad del sistema y que darán lugar a nuevas actuaciones (nuevas evoluciones) sobre el mismo.

Séptima ley de Lehman. Reducción de la calidad

Su enunciado es el siguiente: «La calidad de los sistemas comienza a disminuir a menos que se mantengan de forma rigurosa y se adapten a los cambios en su entorno de funcionamiento (operacional)».

En esta ley, Lehman trata el problema de la disminución de la calidad desde diferentes puntos de vista:

– El usuario tiende a ser más exigente conforme mayor sea la inversión dedicada a la evolución del producto y conforme se den cuenta (independientemente de que sepan interpretar su complejidad o no) de la maleabilidad del software.

– La calidad del software se ve afectada por en incremento de la complejidad del sistema conforme se va evolucionando y eso afecta a diferentes escalas: codificación/arquitectura (deuda técnica), usabilidad, etc…

– Por otro la propia convivencia del sistema con su entorno tecnológico (software y hardware), el cual evoluciona de la misma forma que los sistemas y en muchos casos con características muy similares. En esa evolución se tratan de corregir fallos de seguridad, se trata de dar una mayor estabilidad, a la par de incluir nuevas funcionalidades que puedan resultar de utilidad (y distinguirla de otras opciones del mercado).

Si un sistema no se adapta a esos cambios y las características de los nuevos entornos operacionales que se estén montando no son compatibles, estamos acotando el sistema a seguir subsistiendo con versiones en muchos casos sin soporte de los mismos y que además, se irá quedando marginada porque el esfuerzo central del Departamento de Sistemas se centrará en los entornos en los que se encuentre el grueso de los sistemas de información de la organización, además de aquellos que sean considerados críticos.

El alcance de esta séptima ley se puede extender al propio framework de desarrollo del producto y al conjunto de librerías dependientes que utilice, de manera que surgen nuevas versiones de las mismas que mejoran las anteriores a la vez que corrigen defectos en las mismas.

También puede ser extensible a una menor calidad como consecuencia de no aplicar medidas conforme se incrementa la complejidad del producto (en este caso se asimilaría a la segunda ley de Lehman).

Sexta ley de Lehman. Crecimiento continuo

Su enunciado es el siguiente: «Las funcionalidades del sistema tienen que crecer constantemente para mantener la satisfacción del usuario a lo largo de su ciclo de vida».

Se trata de una particularización de la primera ley de Lehman, solo que en este caso no se habla de adaptación y sí de crecimiento (que como ya hemos visto son conceptos que pueden ser complementarios pero que son diferentes).

Los dos principales fundamentos de esta ley se encuentran:

– En que en el proceso de desarrollo de la aplicación, con el objeto de adecuar el alcance a las posibilidades del proyecto (tiempo, presupuesto, etc…), hay funcionalidades que se descartaron o se postergaron, bien por no considerarse esenciales en ese momento o por no poderse acometer su versión.

– Cuando un sistema presenta problemas a la hora de ponerse en marcha en el conjunto de usuarios, en lugar de ponernos a analizar los motivos por los cuales no cumplen las expectativas, se tiende a pensar que la solución se encuentra en la incorporación de nuevas funcionalidades (que tiendan a tapar o a restar protagonismo a las deficiencias que presente la aplicación).

Con respecto a este segundo fundamento, hoy en día se tratan de racionalizar mucho más los desarrollos, de manera que se trata de buscar la solución más simple que trate de satisfacer las expectativas de los usuarios, lo que hace que solo se tenga en cuenta el desarrollo de nuevas funcionalidades si resulta estrictamente necesario.

Quinta ley de Lehman. Conservación de la familiaridad

Su enunciado es el siguiente: «Cuando un sistema evoluciona, todos aquellos que están asociados a él: desarrolladores, personal de ventas, usuarios, deben mantener un conocimiento de su contenido y comportamiento para tratar de conseguir que la evolución sea satisfactoria. Un crecimiento excesivo disminuye ese conocimiento. De ahí que el crecimiento incremental promedio permanezca invariante».

O lo que es lo mismo, la única manera de que las personas vinculadas al sistema no pierdan el control sobre los cambios que se realizan es que su crecimiento se realice de forma sostenida, de manera que la combinación entre el número, complejidad e impacto de las funcionalidades que se añadan o modifican en cada evolución del sistema se mantenga constante.

También es importante tener en cuenta que cuando un conjunto de personas se acostumbran a una determinada dinámica de funcionamiento del sistema, les resulta más complicado encajar cambios sensibles sobre el mismo. La costumbre se termina imponiendo a nuevas ideas o por lo menos a aquellas que puedan interpretarse como disruptivas.