archivo

Archivos Mensuales: noviembre 2013

La idea que tienen los product owners o los responsables funcionales del software que quieren no es más que algo abstracto, es más, hasta que el producto empiece a materializarse y cobrar una cierta entidad es más acertado decir que su idea inicial es lo que creen que quieren porque hasta que no se empiece a experimentar no saldrán a la superficie comportamientos y funcionalidades deseados pero que estaban ocultos o el caso contrario, comportamientos y funcionalidades que se creían efectivos y útiles y que no son ninguna de esas dos cosas.

De ahí la conveniencia de aplicar desarrollo iterativo incremental y con más razón en aquellos casos donde el sistema se prevea complejo y/o los responsables funcionales no terminen de verlo claro.

Pero desarrollo iterativo incremental es una idea muy general, si definimos ciclos largos hemos fraccionado algo el problema pero probablemente será insuficiente y será mayor la cantidad de desperdicio generado.

También es cuestión de enfoque, mejor siempre partir de soluciones simples consolidadas y validadas para a partir de ahí crecer hacia otras más complejas.

¿Se trata de obtener una versión rápida a toda costa? Versión rápida a toda costa es algo demasiado general, sí que resulta interesante cuanto antes obtener un feedback del usuario pero también que el desperdicio generado sea el menor posible (por lo que los ciclos de desarrollo deben hacerse con intención, de no hacerse así estaremos haciendo desarrollo por permutación y eso tiene un coste importante) y que no perdamos de vista que para seguir generando nuevas versiones es necesario que las modificaciones a realizar sobre el producto se puedan hacer en unos plazos razonables, por lo que en el momento en el que la deuda técnica supere unos determinados umbrales perderemos esa capacidad de respuesta rápida o por lo menos no tan rápida, efectiva y económica como sería deseable.

Tal vez al principio consideres que lo más importante es desarrollar una versión aunque sea prototípica para verificar si el producto va por el camino deseado y que determinados factores como la calidad del código son secundarios. Al final es algo que tendrás que valorar tú en base al contexto en el que estás desarrollando.

La palabra proceso nos crea la imagen mental de burocracia y esto es así no porque nos hayamos levantado de esa manera una mañana sino porque la mayoría de nosotros ha sufrido procesos de desarrollo de software que daban lugar a un mayor coste que a un beneficio real y que estaba lleno de hitos y entregables que se convertían en un obstáculo más que solventar en el ya de por sí complejo camino que son los proyectos de desarrollo de software.

Sin embargo, por mucho que no soportemos los procesos, muy probablemente aplicamos determinadas metodologías, estrategias o prácticas que en esencia también son procesos, lo que pasa es que como muchas de ellas para nosotros son automatismos o confiamos en sus resultados, no las vemos de esa forma.

¿Qué quiero decir con esto? Pues que tal vez el problema no se encuentra en el concepto sino en su definición e implementación, en la falta de una visión orientada a su mejora continua (si un proceso no sufre ajustes algo está pasando) y a la falta de flexibilidad que se ofrece a la hora de adaptarse a las particularidades concretas de cada proyecto.

Un proceso debe aportar, no restar. Si nos pone límites ficticios que dificultan nuestro margen de maniobra quiere decir que nuestros resultados en el proyecto estarán condicionados por impedimentos que perfectamente podrían haberse eliminado, ¿no es absurdo en estos casos abogar por la ortodoxia en lugar de la solución que más conviene?.

En los proyectos de desarrollo de software intervienen infinidad de variables y es el resultado de la colaboración de una serie de personas y no hay nada más impredecible que un ser humano, por ese motivo la definición de los procesos debe tener en cuenta esa circunstancia.

No se trata de acertar a la primera sino de tener capacidad de ir adaptándolo y mejorándolo con la experiencia y de dotar a su aplicación de la flexibilidad suficiente (incluyendo excepciones) para adaptarse lo máximo posible a las necesidades concretas que requiere el proyecto.

Para Miyamoto Musashi: “El resentimiento y la queja no son apropiadas ni para uno mismo ni para los demás”. Son negativas porque nos hacen perder mucha energía y tiempo, además de restarnos concentración y desviar nuestro enfoque a otros lugares o situaciones. Afectan directamente a nuestra productividad y a la calidad de nuestro trabajo.

Pero somos humanos, estamos llenos de emociones, resulta muy complicado ponerle freno al resentimiento o evitar la protesta cuando entendemos que hay una situación que no es justa.

¿Qué hacemos?, ¿es la solución guardarlo todo dentro? No lo es porque si lo haces terminarás minimizándote como persona y perdiendo confianza, lo que a su vez y a la larga dan lugar a otro tipo de problemas.

Lo primero que hay que hacer es evitar las reacciones en caliente porque nos restan objetividad y porque nuestra respuesta será de máxima intensidad y probablemente nos arrepintamos de eso. No es fácil. Quiero matizar que sí que se puede tratar el problema sobre la marcha, pero si sabes o eres consciente de que tratarlo en ese momento se puede escapar de las manos, lo mejor será esperar un poco.

En frío, habrá circunstancias que directamente dejemos de lado porque tras nuestra reflexión y con el paso del tiempo habrán perdido importancia. Otras no, incluso es posible que todavía nos molesten más.

El siguiente paso debería ser analizar la situación desde un punto de vista profesional (entendiendo lo que es nuestro negocio y nuestro entorno, porque de esta forma habremos situado el problema en su contexto adecuado) y pensar si existe alguna manera de darle una solución ya que lo mismo con una conversación o con un café es suficiente. Tratar de arreglarlo es lo mejor, porque en la mayoría de los casos se hace borrón y cuenta nueva.

Si no es posible arreglarlo y necesitas desahogarte, hazlo, pero ten prudencia con quien lo haces, no te vale todo el mundo, solo personas en las que confíes absolutamente. Y una vez hecho eso, trata de poner la situación en un segundo plano hasta que termine siendo insignificante, de manera que tu la controles a ella y no ella a ti. El tiempo es muy bueno para eso.

Es cierto que hay determinadas metodologías que recomiendan que los sprints tengan una duración que se encuentre comprendida en un intervalo de tiempo reducido. Estoy de acuerdo con ellas en que las iteraciones deben ser de corta duración, sobre esa base, mi visión personal es la siguiente:

– Cada proyecto se desarrolla en unas circunstancias y un contexto diferente. Una duración de sprint que resulta adecuada para uno puede no serlo para otro.

– Lo ideal podría ser aplicar sprints de duración fija pero en la realidad resulta complicado ajustarlo de esa manera ya que hay que tener en cuenta diversos factores: falta de disponibilidad en unas fechas concretas del product owner, la necesidad de tener un sprint algo más largo para incluir una funcionalidad esencial, la necesidad de un sprint más corto para solo incluir determinados ajustes, etc… No hay que cerrar las puertas, ni mucho menos a definir sprints de tamaño variable (eso sí, cada sprint tendrá su fecha de inicio y de fin que deberá ser respetada) por mucho que eso se considere poco ortodoxo en la teoría.

Sprints de corta duración permiten dar una rápida respuesta al cambio y obtener feedback cada poco tiempo, esa rápida respuesta no solo es consecuencia de que disminuya el tiempo necesario para llegar a producción sino también por el hecho de que se reduce tiempo de espera para trabajar sobre una funcionalidad no contemplada en el sprint (el tiempo de espera medio es la mitad de la duración de la iteración).

Ahora bien, sprints cortos requieren que el proceso de paso a producción sea rápido porque de lo contrario parte de las ventaja (sino toda) de las iteraciones cortas se quedan en nada. Esta situación no es posible en todas las organizaciones.

Sprints más largos se adaptan mejor a ese inconveniente y admiten más carga de trabajo (proporcional al tiempo).

Ambas soluciones tienen sus ventajas e inconvenientes pero podemos jugar con ellas en función de las necesidades que tenga el proyecto en cada momento, ya que no es ágil cerrarnos en banda a una duración determinada porque estaríamos priorizando la metodología a las necesidades del proyecto y del producto.

Sin embargo, si realmente no se entienden sus fundamentos se puede caer en varios errores típicos, como por ejemplo:

– Que la metodología sea el eje fundamental y que trates de aplicarla tal cual con independencia de lo que le pueda venir mejor al proyecto.

– Que exista precipitación tanto a la hora de iniciar el desarrollo (empezar sin tener una visión inicial del producto lo suficientemente sólida), una iteración (sin historias de usuario lo suficientemente trabajadas o con una priorización errónea) o la construcción de la funcionalidad asociada a una historia de usuario cuando todavía existe demasiada incertidumbre sobre la misma (tal vez se sepa qué es lo que tiene que hacer pero con el inconveniente de que se está pendiente de que se confirme que efectivamente ese es el funcionamiento o se está a la espera de la publicación de una determinada normativa que todavía puede ser modificada, etc…).

– Que sigas con ciertos vicios del pasado, como no prestar atención a tratar de aplicar la solución más simple que resuelva un problema, no prestar atención a la deuda técnica, sobredocumentar, etc…

– Que tu forma de entender tu relación con las personas no haya variado y sigas viendo al cliente, al proveedor o a los responsables funcionales como algo ajeno a tu equipo y sobre los que hay que guardar una cierta distancia y determinadas reservas.

Y cuando no se obtienen resultados, desde la organización, todos aquellos que no entienden la necesidad de cambiar de modelo de desarrollo (pese a que los resultados con otros enfoques sean igual o más nefastos) pondrán más resistencias a que te salgas del guión y también desde un punto de vista personal, al no llegar a entender para qué y por qué aplicas determinadas prácticas o estrategias tenderás a descartarlas porque lo único que andabas buscando es una varita mágica para saldar con éxito tus proyectos y esa varita mágica nunca la vas a encontrar.

La verdad es que resulta muy cool en algunos ambientes empezar a hablar de Scrum, Kanban, XP, Lean, WIP, sprints, pila de producto, kaizen, agile, deuda técnica, etc… porque se da la sensación de que se está al día en un mundo tan cambiante como el del desarrollo de software, aunque otra cosa es que realmente se sepa lo que hay detrás de esas palabras y eso le pasa a muchos porque leer un libro o recibir un curso aunque puede ser importante, no termina de ser suficiente.

Agile hay quien lo considera una moda y no sé si quien piensa eso está equivocado o no, porque si bien es una tendencia sobre la cual hay cada vez más gente interesada en seguirla, no debemos olvidar que el manifiesto ágil es del año 2001 y que sus valores y principios eran ya aplicados por desarrolladores desde mucho antes.

Subirse a la ola del agilismo puede ser algo relativamente sencillo, sin embargo se requiere un tiempo (y experiencias) para poder asimilar sus fundamentos, y de esta manera que realmente llegar a comprender por qué hay cada vez más personas y organizaciones que tratan de utilizarlo en base a los beneficios que proporciona.

La agilidad no es algo a lo que se accede por la aplicación de determinadas prácticas que se puedan considerar ágiles, sino que necesita de algo más, porque realmente se trata de otra forma de entender el desarrollo de software y eso no se consigue de la noche a la mañana.

De esta forma se puede ser ágil en cualquier contexto, incluso en aquellos casos en los que en un proyecto concreto te impongan la aplicación de un enfoque clásico, ya que existirán circunstancias y momentos en los que ante un determinado problema o una determinada decisión se les pueda dar un enfoque ágil y pese a los obstáculos que te puedas encontrar o que te puedan separar con otras personas, nada impide que te crees tu propia visión de las mismas y de cómo debería ser tu relación con ellas.

Con la aplicación de metodologías ágiles se puede empezar a descubrir todo lo que puede aportar a un proyecto y también, por qué no decirlo, a nosotros mismos, porque varía la forma en que interactúan y se comunican las personas dentro y fuera del equipo de desarrollo y se sitúa al producto en el lugar que le corresponde.

El procedimiento o la metodología queda en un segundo plano, como un instrumento, con mayor o menor importancia en cada caso, pero al fin y al cabo como un instrumento.

Respeto mucho a la gente que trabaja duro, a las personas que tienen un nivel de responsabilidad y compromiso para consigo mismo y su equipo (extenderlo a nivel organizativo sería generalizar demasiado porque no son muchas las organizaciones que hace sentir a las personas que trabajan en ellas como parte importante de la mismas). Después las cosas saldrán bien o mal, pero no será por el empeño que se ha puesto.

Ahora bien, si no sale bien, tampoco es cuestión de mala suerte (o por lo menos no se puede recurrir siempre a eso) porque trabajar duro y de manera efectiva no significan lo mismo.

Por ese motivo no se debe ligar productividad a horas trabajadas sino a la efectividad, extendiéndose este último concepto a algo más que completar tareas de manera adecuada, llegando incluso a considerarse como parte del mismo al aprendizaje que vamos obteniendo incluso en aquellos casos donde los resultados no sean todo lo positivos que esperamos.

Si además de no conseguir resultados, no extraemos conocimiento todo será desperdicio.

La productividad entendida de esta manera puede crear controversia porque nos estamos saliendo de la ortodoxia de su concepción clásica, no obstante, si no tenemos en cuenta esos otros activos que se pueden obtener como consecuencia del trabajo que realizamos, estamos dejando fuera del análisis a una parte importante del producto obtenido, intangible, sí, aparentemente (solo aparentemente) inútil, que tal vez no permita recuperar el tiempo perdido pero que más adelante (tal vez mañana mismo) puede producir resultados tangibles y efectivos.