archivo

Archivos Mensuales: julio 2013

La innovación, el progreso y nuestra propia evolución personal y profesional solo son posibles desde el cambio. Puede ser disruptivo o más pausado y supone el abandono de un estado para pasar a una siguiente fase.

Precisamente la dificultad del cambio se encuentra en la necesidad de dejar de lado o reformular determinadas ideas y concepciones, así como aceptar que otras opciones son posibles.

Esto resulta muy complicado cuando se trata de conocimientos o experiencias adquiridas en tu etapa formativa o dentro de tu experiencia profesional, que además se encuentran consolidadas dentro de tu entorno, lo que las convierte prácticamente en un dogma.

En este contexto, toda idea que sugiera un cambio encontrará con la resistencia de ese entorno, ya que no entiende la necesidad de salirse de la ruta establecida y con nuestra propio temor por haber iniciado una línea de actuación diferente, un nuevo camino en el que tal vez, al principio, estemos solos.

Precisamente, uno de los principales problemas de la implantación de enfoques y estrategias ágiles en las organizaciones lo encontramos en la negativa a considerar nuevas alternativas al desarrollo de software que vayan más allá de las tradicionales y de los procedimientos que ya se encuentran establecidos, ya que al fin y al cabo, con más o menos éxito, con más o menos coste, con más o menos sacrificio, son las que se han aplicado hasta ahora y la organización sigue funcionando, de hecho ese será el principal argumento esgrimido tanto exteriormente como internamente (cuando lo estén analizando) por los principales detractores al cambio.

El británico John Maynard Keynes es considerado como uno de los mejores economistas de todos los tiempos y una de las personas más influyentes del siglo pasado. Sobre la dificultad que suponen los cambios realizó la siguiente reflexión: “La dificultad no consiste tanto en el desarrollo de nuevas ideas como en escapar de las antiguas”.

En el artículo de enero de 2001 en la revista IEEE Computer, que Barry Boehm y Victor R. Basili publicaron con el título: “Software Defect Reduction Top 10 List” y que ya mencioné en la entrada: “El impacto del esfuerzo evitable“, hay otra estimación que me pareció muy interesante: “Las prácticas personales disciplinadas pueden reducir la tasa de introducción de defectos en más de un 75%”.

Boehm y Basili en su artículo indican algunos datos empíricos en la aplicación de determinados tipos de metodologías como la PSP de Watts Humphrey, si bien lo importante no es realmente que el término medio sea un 75% o no, sino que todos sabemos en base a nuestra propia experiencia que si se siguen buenas prácticas y una cierta disciplina a la hora no solo de programar sino de probar lo que se desarrolla tanto a nivel de componente, de integración y de sistema el número de errores que se introducen es mucho menor, permitiendo además, detectarlos gran parte de ellos de forma temprana.

Pese a eso, sabemos que existe un mal endémico en los desarrolladores y es que “no se prueba” y eso no es siempre problema de actitud, sino más bien un problema cultural, algo que está ahí, que parece normal y que, sin embargo, provoca un sobrecoste en los proyectos, problemas en el entorno de producción, un desgaste en las relaciones con el usuario, etc…

Alguien resolutivo no es quien te codifica antes un determinado artefacto sino quién es capaz de hacerlo, dentro de un tiempo razonable con el menor número de defectos posible. Es preferible tardar más y hacer un trabajo limpio, que hacerlo en menos tiempo y después estar arreglando problemas mucho más tiempo que el que se entendió que se ganó por hacer el desarrollo tan deprisa.

El cambio de enfoque se puede hacer de manera progresiva, incluyendo esas buenas prácticas y controles de manera paulatina, de manera que las decisiones adoptadas se vayan ajustando a lo que el proyecto necesita. Conforme se vayan consolidando, se considerarán prácticas del trabajo diario, independientemente de que haya proyectos que, por sus condiciones especiales, requieran una mayor exhaustividad.

Sabemos que el desarrollo de software está sustentado por personas y que todo resulta mucho más sencillo (pero no por ello es necesariamente garantía de éxito) si la comunicación e interacción entre ellas es óptima.

No se trata solo de tener actitud sino que la misma esté fundamentada en el convencimiento de que el camino que se está tomando es el correcto o, lo que es lo mismo, que las ideas estén alineadas, independientemente de que se discrepe o haya matices en actuaciones puntuales.

La siguiente reflexión de Charles Eames muestra la clave: “Finalmente todo conecta – personas, ideas y objetos. La calidad de las conexión es la llave de la calidad”.

Cuando existe conexión, lo notas, lo sabes, el proyecto se beneficia de ello. Cuando no la hay, vas directo al precipicio. En medio, toda una gama de grises.

Mantener la conexión es muy difícil porque las personas somos complejas, cometemos errores, vemos las cosas de distinta manera y nuestro estado de ánimo depende de una infinidad de variables.

Si a nivel individual somos complejos, cuando hablamos de relaciones entre grupos de personas, la dificultad crece exponencialmente. Si a eso le sumas la presión del proyecto y/o de tus jefes, todo se hace más cuesta arriba.

Pero no es imposible, por lo que nuestro objetivo debe ser llegar y preservar esa situación de equilibrio porque todo es más fácil cuando hay entendimiento y se persigue un objetivo común.

Hay una reflexión de Jerry Weinberg que es conveniente tener muy en cuenta: “Cuanto más adaptado te encuentres menos adaptable tenderás a ser”.

Esta cita se refiere a la especialización. Puedes ser el rey en un ecosistema concreto, pero como cambie, si no estás preparado, puede ser un desastre para tu organización, porque implicará cambios que deberán ser ejecutados en un tiempo razonable para los cuales no estarán preparadas ni las estructuras ni la mentalidad de la organización y de muchas de las personas, sobre todo los directivos, que forman parte de ella.

La especialización no es mala, no lo entendamos de ese modo, lo que sí es negativo es tener los ojos cerrados a posibles cambios en el contexto, a no tratar de adelantarse a ellos, a pensar que el mercado siempre va a ser el mismo, que la competencia no va a evolucionar lo suficiente y que nosotros siempre vamos a ser los mejores.

Es difícil hacerlo cuando las cosas vienen bien dadas, ¿para qué cambiar si todo va bien?. No se trata de cambiar por cambiar, se trata de hacerlo con cabeza, se trata de mirar alrededor y no solo dentro de uno mismo.

En el mundo actual todo se mueve a un ritmo vertiginoso, de cualquier sitio puede salir un nuevo competidor o una nueva tecnología que puede ser adquirida o desarrollada por tus competidores tradicionales, por ese motivo, no solo debes centrarte en desarrollar tu negocio, sino también estar alerta a riesgos que pueden poner en peligro a tu posición en el mercado.

Comenta Jeff Patton que: “No necesitamos una documentación precisa, sino un conocimiento compartido”.

Esa reflexión no descarta la documentación si bien no le da el monopolio sobre el conocimiento porque la documentación es eminentemente estática y el conocimiento es dinámico, porque la documentación presenta como límite la habilidad del redactor y la comprensión del lector y el conocimiento se basa más en la comunicación y en la interacción, si algo no lo he entendido lo consulto, si en algo no estoy de acuerdo trato de fundamentar otra posible solución (sin menospreciar la base teórica o informativa de los documentos escritos).

Los documentos se pueden utilizar como interfaz entre diferentes grupos de trabajo (siempre y cuando sus actividades no requieran una interacción continua o frecuente o la misma no sea posible, independientemente de que sea deseable), sin embargo, no se debe cometer el error de restringirlo como único canal de comunicación, precisamente por el hecho de que resulta prácticamente imposible que toda la información se haya plasmado adecuadamente y que el propio lector consiga interpretarlo con la misma intención que la persona que lo redactó (todos sabemos que existen tantas percepciones o visiones sobre un determinado asunto como observadores haya).

Por mucho tiempo que se dedique a la redacción del documento, siempre se va a perder información y se van a alimentar los malos entendidos. Cuando se requiere la colaboración continua entre personas o entre equipos, este modelo no funciona.

No hace mucho un amigo me hizo referencia a un proyecto de hace ya algunos años en el que la comunicación entre usuarios y desarrolladores se basaba principalmente en documentos (también existía diálogo, pero la pieza fundamental, eran encuestas, formularios, etc…), ¿podéis imaginaros cuál fue el resultado del proyecto?.

Por otro lado si la interfaz se basa en documentos, se alimenta la distancia entre los equipos, propiciando la aparición del antipatrón “arrojar al otro lado del muro“, en el que el proyecto queda en segundo plano, ante la actitud defensiva que toman los diversos implicados.

Es una regla mnemotécnica para que no olvidemos algo que debería ser una máxima en el desarrollo de software, que no es otra que la búsqueda de la solución más simple que permita satisfacer las expectativas del usuario.

Se denomina principio KISS: “Keep It Simple, Stupid”.

Con una solución simple, que parte de una concepción simple de la historia de usuario o del requisito (para ello el usuario tiene que ayudar olvidándose, al menos en primera instancia, de funcionalidades más complejas de las estrictamente necesarias) y de una ejecución también simple de esa idea.

Es importante que tengamos en cuenta que podemos esforzarnos por simplificar una arquitectura y una codificación, pero para que sea efectiva de verdad, es fundamental que el enfoque de partida sea simple, de lo contrario tendremos una implementación simple de una idea compleja, que dará lugar en la mayor parte de los casos a una solución igualmente compleja, solo que la hemos optimizado internamente con un esfuerzo importante en materia de programación.

El retrabajo es volver a trabajar sobre un determinado desarrollo o la realización de nuevo de una serie de tareas (que puede ser de mayor o menor entidad) y que ha podido ser perfectamente evitable.

Tiene un impacto importante en los proyectos porque es tiempo perdido, esfuerzo que no ha proporcionado ningún valor al proyecto.

En el desarrollo de software estamos acostumbrados a hacer y a rehacer, la diferencia con el retrabajo es la diferencia entre la intención y la negligencia. Se ha podido desarrollar una funcionalidad con intención, de manera meditada y después el usuario descartarla porque una vez desarrollada no le termina de ver utilidad en el sistema.

Se ha ido con una idea concreta y se ha fallado, la negligencia es cuando sin esa reflexión necesaria u obviando soluciones más claras y probables se decide tirar hacia adelante.

Es cierto que entre intención y negligencia hay toda una escala de grises y que cada caso concreto merece su análisis. No obstante, las situaciones extremas son fácilmente identificables y cuando se mete la pata resulta complicado disfrazarlo.

El retrabajo puede ser motivado por el product owner pero también por los desarrolladores.

¿Se quiere mejorar la productividad en los desarrollos? No solo basta con simplificar o eliminar tareas que aportan un valor escaso o nulo con respecto a la inversión necesaria para realizarlas, también es muy importante evitar, en la medida de lo posible, el retrabajo.