archivo

Archivos Mensuales: agosto 2011

Uno de los aspectos más complicados del testing consiste en definir hasta dónde se va a llegar, es decir, qué tipo de pruebas realizar y con qué intensidad, ya que todo el software no tiene la misma criticidad, los mismos recursos para su desarrollo, los mismos plazos, etc…

Es un error aplicar el mismo nivel de testing a todos los productos, ya que podemos pecar por exceso o por defecto (siempre mejor, como es lógico el exceso) y además hay que tener en cuenta que el testing se debería medir más por su efectividad y por su calidad que por el tiempo dedicado al mismo, si bien, se entiende que un equipo formado, aplicando una serie de metodologías y utilizando una serie de herramientas, mantendrá un nivel de efectividad más o menos regular por unidad de tiempo.

A lo anterior hay que añadir que el testing se debe realizar en todo el proceso de desarrollo y no solo al final y que el mismo equipo de proyecto debe participar en el mismo mediante la aplicación de pruebas unitarias, integración continua, pruebas funcionales, verificaciones continuas con el usuario y obtención e implementación del feedback, etc…, independientemente de que existan una serie de profesionales que sean especialistas en realizar este tipo de trabajo.

El testing es muy importante y no una disciplina secundaria, no es algo que se debiera infravalorar, como en el mundo de la programación hay programadores buenos, malos y regulares, lo mismo pasa con los testers. Un producto que llega a producción con errores graves va a costar dinero, de una u otra forma. En algunos casos estos errores serán críticos y el coste será elevadísimo en otros casos provocará un parón en el servicio que no es poco.

Resulta muy interesante la siguiente cita de Weinberg porque refleja bien a las claras lo crítico que resulta en muchas ocasiones el proceso de testing y lo complicado que resulta establecer sus límites (traducción libre): “En septiembre de 1962, saltó a la luz una noticia que indicaba que un cohete de 18 millones de dolares había sido destruido en pleno vuelo debido a un simple guión que faltaba en un programa. La naturaleza de la programación es así, ya que no existe relación entre el tamaño del error y los problemas que causa. Por tanto, es difícil definir cualquier objetivo en el proceso de testing, sin llegar a la eliminación de todos los errores, algo que resulta imposible”.

Anuncios

Son ya ocho años realizando tareas de dirección de proyectos y alguna que otra vez me hago la pregunta de si realmente quiero seguir mucho tiempo haciendo este trabajo o debería enfocarlo en otra dirección, ya sea realizando tareas de más alto nivel o bien otras de una carácter más técnico.

Generalmente me suelo responder que todavía me queda tanto por aprender en el campo de la gestión de proyectos que el mejor sitio donde puedo estar es continuar con este aprendizaje desde las trincheras. Con los buenos y los malos momentos que tiene esta profesión, este perfil, como también lo tienen el resto de roles en un proyecto, cada uno en su momento y cada uno con su nivel de responsabilidad.

Hay muchas cosas que se aprenden en los libros pero hay otras que necesitan ser vividas en primera persona, el desarrollo de software es mucho de conocimiento y experiencia y cada día que pasa más me doy cuenta que sigo necesitando de ambas para intentar hacer mejor mi trabajo porque soy de la opiníón que ya que tengo que trabajar para vivir por lo menos hay que intentar que sirva para algo y esa utilidad no solo está centrada en evolucionar personal y profesionalmente sino que también lo está en intentar que lo que uno hace sirva para mejorar tu entorno. Esto último a veces se consigue, otras muchas no, pero además de los resultados resulta muy importante tener por lo menos esa determinación.

Cada cosa en su momento y en su sitio. El corazón caliente porque te importa en que el proyecto se lleve a cabo con éxito y porque te preocupa que no se cumplan los objetivos marcados y sangre fría a la hora de abordar los conflictos y a la hora de tomar decisiones.

Conseguir ese equilibrio es muy complicado. Llevo ocho años dedicándome a la dirección de proyectos y no lo he conseguido todavía y pese a que pongo empeño no sé si llegaré alguna vez a conseguirlo. Por lo menos aspiro a seguir mejorando día a día.

Yo soy de corazón muy caliente pese a que de trato soy una persona tranquila y desgraciadamente cuando se sobrepasan determinadas fronteras no tengo la sangre fría que debería mantener en esos momentos.

Mejor una palabra de menos que una de más, no hay que olvidar que lo que se dice y cómo se dice tiene mucha importancia y toda razón se puede perder o por lo menos verse erosionada por una actuación desmedida en un momento determinado.

¿En cuántos líos nos hemos metido por no dedicar el tiempo suficiente a pensar en un problema o en una funcionalidad o por no decir que no? Y no lo digo por el hecho de tomar una decisión equivocada sino por el simple hecho de tomar alguna diferente a no abordar en un proyecto determinadas problemáticas y funcionalidades que se escapan de los objetivos principales del mismo.

Invertir esfuerzo en algo que no parece llevar a ningún sitio no parece sensato, sin embargo nuestro afán por ejecutar trabajo y dejar satisfecho a clientes y usuarios nos lleva a meternos por caminos que, a priori, tenemos fundadas sospechas de que no llevan a ningún sitio.

¿Es compatible esto con satisfacer las expectativas de usuario? Por supuesto que sí. De la misma manera que no podemos desarrollar un producto de espaldas al usuario, tampoco el usuario puede orientar el mismo sin tener en cuenta a los técnicos. Se trata de consensuar una solución factible en tiempo y presupuesto, que cumpla las expectativas del usuario (por lo que la opinión de los mismos, como es lógico es la que más peso tiene).

A veces será más sencillo alcanzar ese consenso, otras no y en las que no probablemente o el cliente o el proveedor (o ambos) tendrán que asumir las consecuencias económicas de un alcance que supera al esfuerzo previsto inicialmente.

No hace mucho leí una cita de autor desconocido que describe muy a las claras lo que supone la documentación en un desarrollo clásico o en cascada (podría ser extensible a otros tipos de ciclos de vida, pero en este es donde resulta más acusado su impacto), siempre y cuando se tenga expectativas diferentes de la misma a la que realmente debe tener, que no es otra que la de ser un instrumento para el proceso de desarrollo y no una serie de entregables que acompañan al producto pero que no se utilizan realmente.

La cita es la siguiente: “¿Por qué esperamos que la documentación describa con precisión un producto cuando la documentación se hizo en primer lugar?”.

Insisto mucho en la necesidad de no perder el enfoque en el que debe ser el objetivo real de cualquier proyecto de desarrollo de software que no es otro que satisfacer las expectativas del usuario. Tras ese objetivo hay otros muchos, unos más importantes (como por ejemplo una deuda técnica aceptable, que el proyecto salga en coste y plazos, etc…) y otros que lo son menos.

Habrá proyectos donde tengamos un mayor margen para la creatividad, incluso para la investigación, pero habrá otros donde no será posible. Eso es necesario entenderlo, a veces tendremos proyectos donde podremos aprender más (técnicamente porque en cada proyecto, incluso el más monótono, siempre se gana experiencia) y en otros donde nos tengamos que limitar a hacer nuestro trabajo.

Sobre este aspecto Joshua Bloch, ingeniero de software, empleado de Google y experto en Java (del que es autor de diversas funcionalidades de la plataforma, además de varios libros) realiza la siguiente reflexión: “Nos encanta los rompecabezas. Pero tenemos que atemperar este amor por el conocimiento con el hecho de que estamos resolviendo los problemas reales de personas reales”.

Un exceso de control en el trabajo realizado por tu equipo de proyecto no es bueno, pero no prestar ninguna atención casi que es peor.

Como suele suceder con casi todas las disciplinas la clave está en el equilibrio, hay que respetar los espacios y dar confianza al equipo pero sin perder la noción del estado real del proyecto y de la verificación de que se está cumpliendo el procedimiento y normas especificados en el proyecto.

Todos los equipos y no todos los proyectos son iguales por lo que esa situación de equilibrio será diferente en cada caso, habrá ocasiones donde sea necesario un mayor control y en otras uno menor.

Hacer un seguimiento del trabajo que se está haciendo implica tomar decisiones cuando las cosas no se están haciendo correctamente y hablar con el técnico o técnicos que se han desviado de la pauta marcada para que vuelvan a ellas. Este es principal problema de muchos jefes de proyecto, en muchos casos callar demasiado por no molestar a sus compañeros y en otros hablar más de la cuenta.

Esto es un trabajo, nos podemos llevar estupendamente con nuestros compañeros y muchos de ellos incluso considerarlo amigos, pero hay que entender que somos profesionales y como tal tenemos que comportarnos. No es profesional quedarse callado para no molestar a un amigo, como tampoco lo es tomar medidas desproporcionadas con respecto a un trabajo no adecuado.

Seymour Cray, conocido por su marca de supercomputadores realizó la siguiente reflexión al respecto: “El problema con los programadores es que nunca te das cuenta de que están haciendo hasta que es demasiado tarde”.

De la cita yo me quedo con la necesidad de supervisar el trabajo que se hace pero no con el hecho de que sea un problema de los programadores, ellos hacen su trabajo, otros perfiles deben hacer el suyo.