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.

¿Es compatible generar documentación de un proyecto con la aplicación de principios ágiles? Partiendo de la base de que la agilidad está por encima de las metodologías, por supuesto que sí. Ahora bien, si bajamos el nivel y nos ponemos a nivel de métodos o estrategias ágiles mi opinión es que también, si bien habría que tener siempre en cuenta el contexto del proyecto y el tipo de documentación requerida (en ocasiones la exige el cliente según los procesos que tenga establecidos).

En un enfoque iterativo incremental cada evolución tendrá como objetivo realizar una serie de tareas (pila de sprint) que forman parte de un conjunto de tareas más general (pila de producto). Estas tareas pueden ser de distinta índole: construcción, refactorización, testing, configuración de entornos y, ¿por qué no? Documentación que sirva de base para próximas iteraciones (además de documentación que puede ser de utilidad para el mismo sprint, como por ejemplo documentación de entrega del producto que servirá para su instalación, testing, etc… realizado por personas ajenas al equipo.

Desde esa perspectiva sí que es posible generar documentación siguiendo estrategias o metodologías ágiles si bien hay que entender que la excesiva formalización de la documentación (más de la que el proyecto necesita) supone una resistencia para la evolución del producto: más tiempo para documentar, menos tiempo para desarrollar (y no más documentación supone un mejor desarrollo ya que no se trata de cantidad sino de calidad).

Yo soy partidario de que cada funcionalidad a desarrollar se trabaje de manera que tanto usuarios como programadores sepan qué se va a hacer, ¿estrategia? dependerá del proyecto, de los usuarios, del esquema de trabajo, etc… muchas variables. La historia de usuario supone un instrumento que me gusta bastante: trabajo la historia, aplico técnicas de prototipado si es preciso, no es importante la formalidad y sí el contenido, lo importante es que quede claro lo que se quiere hacer. ¿Habrá huecos en la definión? Es posible, preguntemos lo que sea preciso y decidamos si actualizamos o no la historia en función de la respuesta.

¿Qué hacemos con la historia de usuario tras su construcción y tras la iteración? Es importante registrar lo que se ha hecho en cada iteración y no supone mucho trabajo registrar la historia de usuario asignada a cada tarea.

Opiniones sobre esto hay una por cada desarrollador que existe ya que incluso en visiones parecidas puede haber matices más o menos sensibles. Hay quienes prefieren aplicar ingeniería de requisitos (esto nos lleva hacia metodologías más clásicas si bien es compatible con enfoques iterativos e incrementales) y en el otro extremo historias de usuario de usar y tirar. Cada cual aplica sus conocimientos y experiencia al contexto del proyecto, lo importante es satisfacer las expectativas del usuario y hacer un producto de calidad y mantenible, lo demás son instrumentos, con mayor o menor importancia, pero instrumentos al fin y al cabo.

Trabajas en el contexto de una organización, puede que la misma no funcione bien, no preste atención al proyecto o a tu equipo. Lo mismo no es cosa de la organización (o también) y es cosa de tu inmediato superior (o de su superior), ¿qué te queda?, ¿qué os queda? Vuestra fuerza como equipo.

Si os lo ponen imposible será imposible pero si no es así tendréis la oportunidad de luchar por el proyecto, no digo que se consiga sacar adelante porque lo mismo la resistencia es tal que no se consigue vencer.

Un equipo que funciona como tal, compacto, que se autogestiona, donde se entiende que el trabajo no sale adelante sin la colaboración de todos (cada uno dentro de su rol) es muy potente y es capaz de crear una membrana que lo hace resistente a ingerencias o situaciones externas que afectan al equipo y/o al proyecto.

Por eso es tan importante crear un equipo y si el mismo se extiende a otros stakeholders mejores serán los resultados.

Crear equipos no es tarea sencilla porque no solo depende de quien los coordina sino de la actitud de sus componentes y más difícil todavía resulta mantenerlo en el transcurso del proyecto donde seguro habrá problemas y crisis que será necesario gestionar para no romper esa armonía (o para si se abren pequeñas grietas cerrarlas cuanto antes).

Si entiendes que la simple aplicación de una metodología te hace ágil es que no has entendido realmente lo que es ser ágil. El simple hecho de esconderte tras una metodología, de seguirla como si fuera un dogma te deja desarmado ante la adaptación al cambio porque más allá de la misma te encontrarás el vacío.

Precisamente la explosión de las metodologías ágiles ha sido un arma de doble filo, por un lado ha servido para extender el mensaje y por otro ha podido dar lugar a una mala interpretación del mismo por parte de quienes las practican.

La agilidad no tiene ataduras, puedes usar una metodología pero la misma estará a disposición del proyecto y del contexto y no al revés, ¿que hay que cambiar? si hay causa justificada se cambia y no pasa nada.

No siempre vas a poder aplicar metodologías ágiles porque para ello se tienen que dar una serie de circunstancias en el proyecto que no siempre se producen, eso lo sabemos, ¿tenemos que renunciar entonces a ser ágiles? En absoluto. Nuestro background es ágil y si las circunstancias lo permiten tendremos la oportunidad de aplicar sus fundamentos y principios, tal vez no todos, tal vez en parte, tal vez en alguna ocasión.

La agilidad tampoco es ausencia de metodología porque tener unas reglas del juego proporcionan dinamismo al equipo (que se romperá cuando se quiere mantener una reglas que no sirven para el juego que está ahora mismo sobre el tapete).

La agilidad también consiste en entender que puede haber otros puntos de vista, otra forma de hacer las cosas y en la libertad de cada uno de aplicar las prácticas, estrategias y herramientas que consideren más adecuada al contexto del proyecto.