archivo

Archivo de la etiqueta: software

Me parece muy interesante la siguiente reflexión de Jim Horning: “La importancia de las especificaciones formales finalmente debe descansar en su utilidad en si o no se utilizan para mejorar la calidad de software o para reducir el costo de producción y mantenimiento de software”.

Al final, por tanto, es conveniente tener unos objetivos y medir si esas especificaciones, procesos y metodologías nos están llevando a los mismos y hacer las adaptaciones y rectificaciones que sean necesarias para alcanzar esas metas y también, ¿por qué no?, ajustar esos objetivos a la realidad de la organización, ya que, a veces, se pretende alcanzar unos umbrales que no se corresponden al contexto del mercado, de la organización, etc… o que requiere unos tiempos para alcanzarse que son superiores a las expectativas que se tienen.

No se trata de definir normas de desarrollo de software exclusivamente por el simple hecho de armonizar unos esquemas de funcionamiento de los equipos de trabajo o de las propias arquitecturas del software. Esto es importante y generalmente ofrecerá resultados, pero es conveniente plantearse si es posible mejorar, en qué y qué dirección y sentido se debe elegir para conseguirlo.

Como decía al principio, es importante, muy importante, medir y también recoger las impresiones de las personas que trabajan con esos esquemas de funcionamiento, es importante lo objetivo pero es interesante complementarlo con lo subjetivo porque no siempre se acierta con los indicadores que se miden o simplemente no se está midiendo bien.

A partir de ahí, retrospectivas, análisis y adaptación para que cada vez nos encontremos más cerca de las expectativas.

Anuncios

Me parece muy interesante la siguiente reflexión de Dave Thomas: “Queremos que la gente vea el software como algo más orgánico, como algo más maleable y algo con el que tengas que estar preparado para interactuar con él y mejorarlo todo el tiempo”.

Esta reflexión está relacionada con una cita de Andy Hunt y Dave Thomas de su libro “The Pragmatic Programmer”: “En lugar de a la construcción el software se parece más a la jardinería” y en la justificación de dicha afirmación por parte del propio Dave Thomas (traducción libre): “En los jardines existe la suposición de que va a tener un mantenimiento constante. Todo el mundo dice que quiere un jardín que no requiera mucho mantenimiento pero al final es un jardín es algo con lo que siempre estás interactuando bien sea para mejorarlo o mantenerlo”.

Yo también veo el desarrollo de software así. La realidad demuestra que los procesos que se informatizan están en continua evolución, cambian normativas, se quiere buscar una mejora continua, se quiere ser competitivo. Por otro lado el software por sus características es un elemento que puede ser mantenido y mejorado sin necesidad de interrumpir el funcionamiento normal del sistema, incluso cuando se realizan modificaciones radicales sobre el mismo (salvo en aquellos casos donde el cambio en el proceso sea tan abrupto que haga el sistema inútil de la noche a la mañana, cosa que si bien puede pasar, no es lo más frecuente).

El software va a requerir mantenimiento (o mejor dicho, evolución), por ese motivo hay que pensar en tiempo de desarrollo la estrategia más adecuada para reducir la necesidad y los costes de mantenimiento. Desarrollar dejando eso en segundo plano después cuesta mucho dinero y problemas.

Para Jeff Sutherland: “El compromiso de trabajar juntos sólo ocurre cuando las personas están de acuerdo en objetivos comunes y luego luchan para mejorar como personas y como equipo”.

Precisamente por eso es tan complicado alcanzar ese compromiso y por eso creo que se requiere un cierto bagaje personal y profesional para entender qué ventajas supone trabajar de esta manera y lo necesario que resulta para sacar adelante los proyectos.

Los equipos funcionan cuando existe un compromiso entre los miembros del equipo. Cuando cada cual va por su cuenta no estamos hablando de equipo sino de un conjunto de personas que comparten un espacio físico.

El compromiso es dar lo mejor de nosotros mismos por el equipo y por el proyecto y exigir a los demás que hagan lo mismo. Si el nivel de exigencia no es justo favoreciendo a unos sobre otros, no se debe llamar compromiso, sino amiguismo ya que el compromiso solo tienes con unos cuantos y esos cuantos contigo.

Tampoco son buenas las políticas del todo el mundo es bueno, porque generalmente cuando se aplican es precisamente para evitar ciertas decisiones poco agradables. Lo fácil siempre es hacer la media aritmética y tratar a todos por igual lo hagan bien o lo hagan mal, estén comprometidos o no. Este tipo de estrategias hacen mucho daño a aquellas personas que precisamente ofrecen un mayor compromiso.

Cuando un equipo funciona tiene como consecuencia natural la autogestión en la que cada miembro del equipo asume su responsabilidad y se resuelven los conflictos en el equipo (salvo que por su trascendencia tengan que escalarse).

Para Bob C. Martin un software que presenta algunos de los siguientes defectos tiene un mal diseño:

1) Rigidez: Es complicado realizar cambios porque cada cambio afecta a otras partes del sistema.
2) Fragilidad: Cuando realizas un cambio, partes insospechadas del sistema empiezan a fallar.
3) Inmovilidad: Es difícil reutilizar código en otra aplicación porque no puede ser separado de la aplicación en la que se está usando.

Es importante incidir en que Martin se está centrando en aspectos de diseño y de arquitectura y no en aspectos de programación (pese a que al final estos problemas se hagan evidentes en el proceso de desarrollo y en las actividades de mantenimiento o evolución del sistema), por ese motivo los defectos que plantea están relacionados con factores como la modularidad, el alto acoplamiento, la baja cohesión y la alta complejidad ciclomática (entre otros).

Un buen diseño se valora cuando has trabajado con sistemas que no lo tienen, en los cuales realizar cualquier tarea de mantenimiento se encuentra con una resistencia que hace que los costes se disparen, sin que por ello se garantice que el producto va a pasar a producción con menos errores que los que tenía antes.

Para Brian Kernighan el control de la complejidad es la esencia de la programación.

Complejidad supone más esfuerzo en la construcción y en el mantenimiento, más probabilidad de que existan errores y sistemas de información más complicados de utilizar para el usuario.

La complejidad es resistencia al progreso en el desarrollo y resistencia cuando se trata de adaptarnos al cambio.

La complejidad es agotadora para los desarrolladores y una carga que lleva el producto durante todo su ciclo de vida.

Es necesario hacer un esfuerzo en todas las etapas del proyecto, desde su concepción hasta su entrega con el objetivo de encontrar la solución más simple que satisfaga las expectativas del usuario (y que permita un mantenimiento lo más simple posible ajustado a las características del sistema).

Buscar lo más simple implicará entender bien los procesos de fondo que informatiza el sistema, pensar en el usuario, pensar en el software es susceptible de ser modificado en todo su ciclo de vida, pensar en que hay que ser prácticos (tanto desarrolladores como usuarios) y no llenar el producto de funcionalidades que no se utilizan o que van a tener un uso residual.

Entregar por entregar una versión de un producto es algo que desgraciadamente estamos muy habituados a ver.

La entrega de software de baja calidad tiene consecuencias negativas, muchas más que si no hubieras entregado el producto a tiempo (por regla general):

– Cuando se entrega un software y se rechaza no solo estás perdiendo tiempo y dinero tú, sino también el cliente.

– Cuando se entrega un software con un elevado número de errores se incrementa la probabilidad de que alguno de ellos y de importancia llegue a producción, lo que puede provocar la liberación de un nuevo parche o de una serie de parches. Con eso también pierde dinero el cliente (mucho más ya que ha podido dejar bloqueado total o parcialmente un proceso, lo que ha provocado que una serie de trabajadores estén por debajo de su rendimiento habitual) y también lo perderás tú.

– Cuando se entrega un software con una deuda técnica alta estás condicionando su evolución, aquí también pierde dinero el cliente por el coste extra que tendrán las tareas de mantenimiento y por los posibles efectos colaterales que provoquen las nuevas versiones (si el software se encuentra muy acoplado y el testing no es suficiente) y también lo perderás tú, sobre todo si trabajas en proyectos a coste fijo.

Entregar software a la ligera por el simple hecho de cumplir una fecha o por pensar que no pasa nada, que ya se corregirán los defectos hace mucho daño, no solo al proyecto, ya que cuando se generalizan esas prácticas también se hace mucho daño a la profesión. Si queremos mejorar nuestras condiciones y la percepción que terceros tienen de nosotros necesitamos que no se nos vea como chapuceros.

Jeff Sutherland entiende que (traducción libre): “Los miembros del equipo deben compartir un propósito y visión común, además de pasión por su trabajo. Los equipos no son solo un conjunto de personas que trabajan juntas, sino que todas deben estar comprometidos con su trabajo y con el de los compañeros”.

Coincido con él, para mi eso es realmente un equipo.

Sin embargo lograrlo no es nada sencillo sobre todo teniendo en cuenta lo variables e impredecibles que somos las personas y que cada cual tenemos una forma de ser que supone nuestro background en la relación con nuestro entorno. A lo anterior hay que sumar el contexto individual de cada persona en su vida profesional y personal y el contexto en el que el equipo realice su trabajo (hay veces donde las circunstancias no ayudan a la cohesión de un equipo).

No se trata, por tanto, de colocar a una serie de personas en una habitación, dar una charla y ponerse a trabajar, se requiere mucho más para llegar a tener un equipo que funcione como tal, para empezar que cada uno crea que este es el camino para lograr los objetivos del proyecto pero que también lo es para conseguir los objetivos del grupo y los individuales.

Después las propias necesidades de la organización también condicionan todo, si un proyecto termina puede provocar que el equipo se disgregue entre otros equipos existentes en la organización y la química en estos nuevos equipos no será la misma, por lo menos durante un tiempo.

Ahora bien, si un equipo funciona hay que intentar por todos los medios mantenerlo unido, salvo que integrantes del mismo quieran rotar. Para eso puede ser interesante tener una cultura de trabajo en equipo en la organización y si no es posible, por lo menos en los proyectos que sean de tu responsabilidad porque de esta forma las rotaciones no solo tendrán menos impacto sino que incluso pueden ser beneficiosas para incrementar sus habilidades y experiencia.