archivo

Archivos Mensuales: febrero 2014

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.

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.

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.

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?.

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).

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.

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.