archivo

Archivos diarios: abril 18, 2012

Ya lo he comentado anteriormente, saber decir que no es una de las mejores técnicas de productividad que conozco, tal vez la mejor.

No se trata de decir que no de manera arbitraria, se trata de decir que no cuando hay que realizar una tarea que no te corresponde existiendo otra persona que la puede hacer y que sí le corresponde esa tarea (es conveniente tener en cuenta que ante todo está el sentido común y si puedes echar una mano se echa y si otra persona está muy apurada y tu lo estás menos, también lo puedes hacer, pero eso debe ser una decisión personal) y se trata de decir que no cuando te piden hacer una tarea que no siendo importante requiere un esfuerzo mucho mayor que el beneficio que se va a obtener realizándola.

Se trata de decir que no, no solo a iguales dentro de una organización, sino también a personas que están en un nivel jerárquico superior, ahí es donde cuesta decir que no y donde decirlo puede tener un precio.

Tienes que valorar a quién le dices que no y cuáles son tus argumentos. Hay personas que por muchos argumentos que tengas no aceptarán un no o si lo hacen, lo más probable es que tarde o temprano, de alguna u otra forma, te termine pasando factura.

Hay otras personas que sí aceptarán tus argumentos aunque en primera instancia se muestren contrariados por tu postura (después te lo agradecerán).

Hay de todo y tienes que analizar en cada situación lo que más conviene tanto al proyecto como a ti. Es muy fácil aconsejar que hay que decir que no siempre que exista una justificación para ello, sobre todo si no eres tú quien tiene que asumir las consecuencias.

Hace poco, a modo de crítica sobre el enfoque ágil en el desarrollo de software, me comentaron que la visión ágil está centrada en el corto plazo, dejando de lado lo que es el medio y el largo plazo tanto en la realización de un proyecto como en lo que el sistema de información en sí.

No estoy de acuerdo, ser agilista y cortoplacista no es lo mismo, es más, no tienen nada que ver. Tener la capacidad de adaptarte rápido al cambio y hacerlo cuando es preciso no es ver las cosas a corto plazo sino actuar lo antes posible antes de que el problema vaya a más.

Es más, no se puede ser ágil sin tener una visión a medio o largo plazo, ya que precisamente se trata de actuar con intención, con el enfoque en conseguir los objetivos y para ello hay que saber hacia donde se quiere ir, para ello hay que ir de la mano con un plan, que estará sujeto a las sucesivas adaptaciones que sean necesarias hacer en el mismo, no de manera arbitraria, sino en respuesta a una situación.

Comenta Steve McConnell que: “El testing por sí solo no mejora la calidad del software […] Si quieres mejorar tu software, no hagas más testing, desarrolla mejor”.

El testing es un instrumento para intentar mejorar en lo posible una variable importante y nada despreciable de la calidad del software y es que éste funcione y que se puede aplicar desde una visión unitaria del software hasta la visión general del sistema de información en funcionamiento. El testing puede combinar desde tareas automatizables hasta otras que requieren la intervención humana.

El testing es una estrategia dentro del proceso de desarrollo de software pero que no soluciona el problema de fondo de unas malas prácticas de gestión, análisis y programación en las que se no se tenga en cuenta las expectativas del usuario a la hora de diseñar e implementar soluciones, la deuda técnica o el número de errores que se integran en la línea principal del producto y que no son detectables por un testing automático.

Por tanto, una mejora de la calidad del software requiere en primer lugar un cambio de actitud por parte de los desarrolladores en la que éste sea su eje de actuación y no el hecho de ejecutar trabajo y en segundo lugar, partiendo del cambio de actitud un cambio en el proceso de desarrollo de software. Dentro de ese proceso se encontraría el testing aplicable en mayor o menor profundidad en función del proyecto, de la organización, del equipo que participa en él, etc…

McConnell no quiere decir que el testing sea prescindible, lo que hace es incidir que la mejora del proceso no pasa por establecer más mecanismos de control, sino por cambios en el propio proceso, sin que eso quiera decir que los mecanismos de control no sean válidos o útiles (siempre orientados al proyecto y a los propios procesos de desarrollo).