archivo

Archivos Mensuales: octubre 2012

Tener la capacidad de responder a un cambio de contexto lo antes posible, incluso de anticiparse o tener la capacidad de crear una tendencia solo puedo hacerse desde unas bases flexibles que permitan actuar de forma rápida.

Estas bases son los propios procesos organizativos pero también es cuestión de mentalidad (en general de la organización porque la adaptación al cambio es un esfuerzo común pero sobre todo de las personas que tienen poder de decisión tanto en la dirección como en los mandos intermedios). Es más, me atrevería a decir que es casi más mentalidad que procesos porque estos siempre dependerán de personas que harán más flexibles o rígidos los procesos o que incluso, llegado el momento los pueden obviar si fuera necesario.

Ahí es donde entra en juego la agilidad.

La importancia de adaptarse rápidamente al cambio no solo es cosa del desarrollo de software sino en general a cualquier aspecto de la vida. En el mundo de los negocios y de las empresas no adaptarte rápido al nuevo entorno o a un nuevo segmento de mercado puede suponer tu desaparición como organización o la insignificancia más absoluta de tu organización dentro de él.

A todo esto hay que añadirle el hecho de que los cambios de contextos, de tendencias, la aparición de más competencia y con nuevas ideas, etc… es algo continuo, no va a parar. En ocasiones requerirán menos esfuerzo de adaptación y en otras supondrá el replanteamiento o redefinición completa de determinadas líneas de actuación de la organización.

La siguiente cita de Jim Highsmith resume en pocas palabras esta circunstancia: “La agilidad es la capacidad tanto de crear como de responder a los cambios con el objetivo de obtener beneficios en un entorno empresarial turbulento”.

Hay que ir más allá de los casos de prueba o de las fuentes que se tengan para poder realizar este tipo de testing: casos de uso, requisitos, historias de usuario, etc… porque resulta muy complicado que la documentación disponible cubra todas las casuísticas que se han desarrollado (aún cubriéndolas, que hayan descendido al nivel de detalle necesario en todos los casos) y porque una cosa son las especificaciones y otra los componentes software que se han desarrollado y su engranaje.

Lo ideal es la combinación de ambos tipos de testing (basado en casos de prueba y exploratorio) porque el testing exploratorio salvo que se tenga colaboración del equipo de proyecto o lo recursos del proyecto permitan conocer bien el negocio, no podrá corroborar de manera adecuada el funcionamiento del sistema.

El testing exploratorio básicamente consiste en realizar el testing con los recursos disponibles y en donde la habilidad, conocimientos y experiencia del tester o del equipo de testing resultan fundamentales para hacer un trabajo de calidad. Desde este punto de vista también cabría dentro de este testing la aplicación de los casos de prueba basado en documentación existente en el proyecto: “esta es la documentación que hay, tu te lo guisas y tu te lo comes”, si bien me gusta hacer una diferenciación entre un caso y otro ya que en uno hay una intención de hacer una documentación que pueda ser de utilidad para las pruebas (aunque no sea ese su propósito principal) y en el caso del testing exploratorio se basaría más en ir recopilando piezas (documentales, prototipos, consultas al equipo de desarrollo, etc…) y en el trabajo en profundidad con el producto.

Un amigo me comentó una vez que una cosa es la verificación de aspectos relacionados con la arquitectura del software, buenas prácticas y deuda técnica y otra cosa es el testing y que la mezcla de todos esos conceptos no produce buenos resultados porque se pierde el enfoque en lo realmente importante de cada una de esas áreas.

¿Cuál es mi opinión? Pues que todo es cuestión de definir adecuadamente cuáles son los objetivos en el caso de que todas esas tareas sean realizadas por un mismo equipo.

El esfuerzo de un equipo de testing debe centrarse en localizar el mayor número de errores posibles y los mismos no solo son consecuencia de un mal funcionamiento sino también pueden ser provocados por falta de coherencia funcional (algo muy común) o por problemas de carácter no funcional.

Ese trabajo no es sencillo, hacerlo bien requiere conocimientos y experiencia, sobre todo en contextos donde tienes que ir más allá de una documentación de referencia (algo que ocurre también muy a menudo) y en donde las exigencias son altas.

El testing merece respeto y si desgraciadamente no tiene el que merece no solo es provocado por la actitud de los programadores (que en mi opinión deberían hacer una reflexión al respecto) sino por un mal enfoque y unas malas prácticas que han provocado que en muchas ocasiones el esfuerzo dedicado al testing no haya obtenido unos resultados proporcionales al mismo.

En cierto modo le pasa lo mismo que al desarrollo de software donde los propios desarrolladores nos hemos encargados de maltratar nuestra profesión.

Los dos principales motivos que hacen que los presupuestos de partida y las planificaciones (incluso a muy alto nivel) no se ajusten posteriormente a la realidad son:

– La incertidumbre. Sabes que va a haber contingencias en el transcurso del proyecto y que las mismas afectarán al presupuesto y los plazos. Puedes aplicar un colchón de seguridad en función de las variables que conozcas del proyecto: tecnología, complejidad, cliente, etc…, pero incluso contemplando ese factor las posibilidades de error siguen siendo importantes porque prevés un comportamiento de esas variables en base a la experiencia anterior (en el presente el contexto puede ser diferente y, por tanto, el comportamiento también) y porque hay variables que sencillamente no controlas.

– El desconocimiento. Muchas veces se presupuesta y planifica sin conocer las expectativas del área usuaria y la complejidad funcional real que va a tener el sistema. Se tienen ideas generales y sobre eso se construye una hoja de ruta, acertar en base a esto es casi un milagro.

Al final, el presupuesto y los plazos serán restricciones que condicionarán el proyecto y que si están lejos de la realidad (en muchos casos es así) condicionarán a la calidad del producto final.

Sé que trabajar con un presupuesto fijo da tranquilidad: “Tengo la previsión de gastarme X para obtener Y”, pero en el desarrollo de software para obtener Y te tienes que gastar Z que puede ser menor, igual o mayor (casi siempre) que X.

No se trata de tener barra libre. El presupuesto tiene que ser bien gestionado e invertido pero es importante tener presente que si el objetivo real es tener un sistema de información acorde a las expectativas que se tenían en él (tanto a nivel funcional como no funcional) no podemos estar atados a la inflexibilidad de un presupuesto fijo e inamovible.

La siguiente cita de Roy Miller refleja algo, desgraciadamente, demasiado frecuente dentro de nuestra profesión: “Lo malo de gran talento técnico es la actitud suele aparecer junto con él. Es difícil encontrar un gran programador que no cree que está un peldaño por encima de los simples mortales”.

Cuando un día sientas que no has sido humilde piensa que ese día te has equivocado. Si sientes que generalmente no eres humilde tienes un problema.

Ten en cuenta que trabajas con otras personas, que no estás solo y que las vas a necesitar de la misma forma que ellos te necesitan a ti. La mejor forma de trabajar de manera cooperativa, con comunicación, interacción es tratando a tus compañeros con respeto y ese respeto se pierde cuando empiezas a desechar otras ideas, sin siquiera analizarlas, por el simple hecho de que vienen de alguien con menos capacitación que tú.

No se trata de que dejes de ser un gran desarrollador sino de que pienses que tu objetivo no es brillar por ti solo y que hablen con admiración de tu gran talento sino de desarrollar toda tu capacidad en los proyectos haciendo que tus compañeros trabajen mejor, para que de esta forma ellos hagan que tú también puedas conseguir mejores resultados.

Un talento que no consigue resultados no me vale y difícilmente los conseguirá si no entiende que no trabaja solo.

La microgestión o gestión orientada al detalle tiene un importante overhead tanto por parte de quiénes realizan las tareas como por parte de quien las supervisa. Trabajar de esta manera requiere una gran disciplina de manera que solo se tiene actualizado el estado de las tareas si quienes se encargan de su ejecución tienen muy asimilada esta forma de trabajar.

Otro inconveniente importante es que se crea un contexto de escasa flexibilidad ya que los objetivos se equivocan: lo importante es realizar las tareas asignadas a tiempo sean o no lo que convenga al proyecto o aunque hayan cambiado las circunstancias. ¿Que no hay problemas en cambiar la planificación? Pues nada, a actualizar se ha dicho y el tiempo invertido en ese ajuste dependerá del cambio realizado en la planificación y de la cantidad de trabajo planificado. Este trabajo es a veces tan ingente que con tal de no tener que hacerlo se realiza la tarea y punto.

Pero de todos los posibles inconvenientes el más significativo y con diferencia es que la microgestión no se lleva bien por las circunstancias indicadas: excesivo overhead y falta de flexibilidad con una situación de incertidumbre como rodea a los proyectos de desarrollo de software.

No se trata de no saber qué es lo que se va a hacer hoy o de que podamos seguir como va evolucionando el proyecto pero la verificación del cumplimiento de los objetivos se debe realizar a más largo plazo, ¿cuánto? dependerá del contexto de la actividad, de la tarea o del proyecto.

Con la microgestión se crea una falsa sensación de control: “tengo todo planificado, al detalle, si surge un imprevisto siempre podré reaccionar a tiempo porque sé como va todo y qué está haciendo cada uno”, ¿alguien se cree que de esta forma se tiene un mayor control? Yo no digo que no, dependerá del gestor y del equipo, pero lo que no creo es que de esta manera se responda mejor al cambio, es decir, no creo que el esfuerzo que requiere (y si la gente es sincera indicando el estado real de las tareas) merezca los resultados que, por regla general, va a ofrecer.

Hoy has podido tener un día extraordinario o haber vivido un día terrible. Hoy has podido finalizar un proyecto con un éxito rotundo o haber cosechado un estruendoso fracaso. Todos sin excepción vivimos días extraordinarios y terribles y todos hemos tenido éxitos y fracasos en nuestros proyectos.

Tras esos días, viene el de después y ese día en cualquier caso es difícil. Cuando te crees que estás arriba porque no puedes subir más (a corto plazo), cuando estás abajo porque no ves forma de levantar cabeza.

La actitud que tengas el día después te condicionará tu futuro próximo, si decides seguir luchando te será más fácil conservar tu éxito y remontar tu fracaso, si te quedas mirando hacia atrás te será complicado seguir hacia adelante.

Tras el día después, habrá otro que te dará la oportunidad de volver a retomar el camino correcto si el día anterior no te sentiste con fuerza.